From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 815EDC433B4 for ; Sat, 8 May 2021 07:53:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 514E761456 for ; Sat, 8 May 2021 07:53:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230182AbhEHHxi (ORCPT ); Sat, 8 May 2021 03:53:38 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:17159 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229726AbhEHHxh (ORCPT ); Sat, 8 May 2021 03:53:37 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FcfbJ3r6jzncJJ; Sat, 8 May 2021 15:49:16 +0800 (CST) Received: from [10.67.110.238] (10.67.110.238) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.498.0; Sat, 8 May 2021 15:52:25 +0800 Subject: Re: Virtio-scsi multiqueue irq affinity To: Ming Lei , Thomas Gleixner CC: Peter Xu , Christoph Hellwig , Jason Wang , Luiz Capitulino , "Linux Kernel Mailing List" , "Michael S. Tsirkin" , , References: <20190318062150.GC6654@xz-x1> <20190325050213.GH9149@xz-x1> <20190325070616.GA9642@ming.t460p> <20190325095011.GA23225@ming.t460p> From: xuyihang Message-ID: <0f6c8a5f-ad33-1199-f313-53fe9187a672@huawei.com> Date: Sat, 8 May 2021 15:52:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20190325095011.GA23225@ming.t460p> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.110.238] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ÔÚ 2019/3/25 17:50, Ming Lei дµÀ: > On Mon, Mar 25, 2019 at 09:53:28AM +0100, Thomas Gleixner wrote: >> Ming, >> >> On Mon, 25 Mar 2019, Ming Lei wrote: >>> On Mon, Mar 25, 2019 at 01:02:13PM +0800, Peter Xu wrote: >>>> One thing I can think of is the real-time scenario where "isolcpus=" >>>> is provided, then logically we should not allow any isolated CPUs to >>>> be bound to any of the multi-queue IRQs. Though Ming Lei and I had a >>> So far, this behaviour is made by user-space. >>> >>> >From my understanding, IRQ subsystem doesn't handle "isolcpus=", even >>> though the Kconfig help doesn't mention irq affinity affect: >>> >>> Make sure that CPUs running critical tasks are not disturbed by >>> any source of "noise" such as unbound workqueues, timers, kthreads... >>> Unbound jobs get offloaded to housekeeping CPUs. This is driven by >>> the "isolcpus=" boot parameter. >> isolcpus has no effect on the interupts. That's what 'irqaffinity=' is for. > Indeed. > > irq_default_affinity is built from 'irqaffinity=', however, we don't > consider irq_default_affinity for managed IRQ affinity. > > Looks Peter wants to exclude some CPUs from the spread on managed IRQ. Hi Ming and Thomas, We are dealing with a scenario which may need to assign a default irqaffinity for managed IRQ. Assume we have a full CPU usage RT thread running binded to a specific CPU. In the mean while, interrupt handler registered by a device which is ksoftirqd may never have a chance to run. (And we don't want to use isolate CPU) There could be a couple way to deal with this problem: 1. Adjust priority of ksoftirqd or RT thread, so the interrupt handler could preempt RT thread. However, I am not sure whether it could have some side effects or not. 2. Adjust interrupt CPU affinity or RT thread affinity. But managed IRQ seems design to forbid user from manipulating interrupt affinity. It seems managed IRQ is coupled with user side application to me. Would you share your thoughts about this issue please? Thanks, Yihang