From: Hannes Reinecke <hare@suse.de>
To: Ming Lei <ming.lei@redhat.com>, Daniel Wagner <dwagner@suse.de>
Cc: Jens Axboe <axboe@kernel.dk>, Keith Busch <kbusch@kernel.org>,
Sagi Grimberg <sagi@grimberg.me>,
Thomas Gleixner <tglx@linutronix.de>,
Christoph Hellwig <hch@lst.de>,
Frederic Weisbecker <fweisbecker@suse.com>,
Mel Gorman <mgorman@suse.de>,
Sridhar Balaraman <sbalaraman@parallelwireless.com>,
"brookxu.cn" <brookxu.cn@gmail.com>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH v2 3/3] lib/group_cpus.c: honor housekeeping config when grouping CPUs
Date: Mon, 1 Jul 2024 10:43:14 +0200 [thread overview]
Message-ID: <0d8a5256-9719-45c5-b098-237b5a82fd36@suse.de> (raw)
In-Reply-To: <ZoJY6a1CHCENAZZ8@fedora>
On 7/1/24 09:21, Ming Lei wrote:
> On Mon, Jul 01, 2024 at 09:08:32AM +0200, Daniel Wagner wrote:
>> On Sun, Jun 30, 2024 at 09:39:59PM GMT, Ming Lei wrote:
>>>> Make group_cpus_evenly aware of isolcpus configuration and use the
>>>> housekeeping CPU mask as base for distributing the available CPUs into
>>>> groups.
>>>>
>>>> Fixes: 11ea68f553e2 ("genirq, sched/isolation: Isolate from handling managed interrupts")
>>>
>>> isolated CPUs are actually handled when figuring out irq effective mask,
>>> so not sure how commit 11ea68f553e2 is wrong, and what is fixed in this
>>> patch from user viewpoint?
>>
>> IO queues are allocated/spread on the isolated CPUs and if there is an
>> thread submitting IOs from an isolated CPU it will cause noise on the
>> isolated CPUs. The question is this a use case you need/want to support?
>
> I have talked RH Openshift team weeks ago and they have such usage.
>
> userspace is free to run any application from isolated CPUs via 'taskset
> -c' even though 'isolcpus=' is passed from command line.
>
> Kernel can not add such new constraint on userspace.
>
>> We have customers who are complaining that even with isolcpus provided
>> they still see IO noise on the isolated CPUs.
>
> That is another issue, which has been fixed by the following patch:
>
> a46c27026da1 blk-mq: don't schedule block kworker on isolated CPUs
>
Hmm. Just when I thought I understood the issue ...
How is this supposed to work, then, given that I/O can be initiated
from the isolated CPUs?
I would have accepted that we have two scheduling domains, blk-mq is
spread across all cpus, and the blk-mq cpusets are arranged according
to the isolcpu settings.
Then we can initiate I/O from the isolated cpus, and the scheduler
would 'magically' ensure that everything is only run on isolated cpus.
But that patch would completely counteract such a setup, as during
I/O we more often than not will invoke kblockd, which then would cause
cross-talk on non-isolated cpus.
What is the idea here?
Confused,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
next prev parent reply other threads:[~2024-07-01 8:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-27 14:10 [PATCH v2 0/3] nvme-pci: honor isolcpus configuration Daniel Wagner
2024-06-27 14:10 ` [PATCH v2 1/3] blk-mq: add blk_mq_num_possible_queues helper Daniel Wagner
2024-06-28 6:02 ` Christoph Hellwig
2024-06-28 6:23 ` Hannes Reinecke
2024-06-30 8:24 ` Sagi Grimberg
2024-06-27 14:10 ` [PATCH v2 2/3] nvme-pci: limit queue count to housekeeping CPUs Daniel Wagner
2024-06-28 6:03 ` Christoph Hellwig
2024-06-28 6:24 ` Hannes Reinecke
2024-06-30 8:25 ` Sagi Grimberg
2024-06-27 14:10 ` [PATCH v2 3/3] lib/group_cpus.c: honor housekeeping config when grouping CPUs Daniel Wagner
2024-06-28 6:03 ` Christoph Hellwig
2024-06-28 6:24 ` Hannes Reinecke
2024-06-30 8:25 ` Sagi Grimberg
2024-06-30 13:39 ` Ming Lei
2024-07-01 7:08 ` Daniel Wagner
2024-07-01 7:21 ` Ming Lei
2024-07-01 8:19 ` Daniel Wagner
2024-07-01 8:47 ` Ming Lei
2024-07-01 8:43 ` Hannes Reinecke [this message]
2024-07-01 9:16 ` Ming Lei
2024-07-01 2:09 ` Ming Lei
2024-07-01 6:43 ` Hannes Reinecke
2024-07-01 7:10 ` Ming Lei
2024-07-01 8:37 ` Hannes Reinecke
2024-07-02 7:25 ` Daniel Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0d8a5256-9719-45c5-b098-237b5a82fd36@suse.de \
--to=hare@suse.de \
--cc=axboe@kernel.dk \
--cc=brookxu.cn@gmail.com \
--cc=dwagner@suse.de \
--cc=fweisbecker@suse.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mgorman@suse.de \
--cc=ming.lei@redhat.com \
--cc=sagi@grimberg.me \
--cc=sbalaraman@parallelwireless.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox