[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d11a0c60-1b75-49ec-a2f8-7df402c4adf2@flourine.local>
Date: Mon, 8 Sep 2025 09:26:05 +0200
From: Daniel Wagner <dwagner@...e.de>
To: Hannes Reinecke <hare@...e.de>
Cc: Daniel Wagner <wagi@...nel.org>, Jens Axboe <axboe@...nel.dk>,
Keith Busch <kbusch@...nel.org>, Christoph Hellwig <hch@....de>, Sagi Grimberg <sagi@...mberg.me>,
"Michael S. Tsirkin" <mst@...hat.com>, Aaron Tomlin <atomlin@...mlin.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>, Thomas Gleixner <tglx@...utronix.de>,
Costa Shulyupin <costa.shul@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
Valentin Schneider <vschneid@...hat.com>, Waiman Long <llong@...hat.com>, Ming Lei <ming.lei@...hat.com>,
Frederic Weisbecker <frederic@...nel.org>, Mel Gorman <mgorman@...e.de>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
linux-nvme@...ts.infradead.org, megaraidlinux.pdl@...adcom.com, linux-scsi@...r.kernel.org,
storagedev@...rochip.com, virtualization@...ts.linux.dev,
GR-QLogic-Storage-Upstream@...vell.com
Subject: Re: [PATCH v8 10/12] blk-mq: use hk cpus only when isolcpus=io_queue
is enabled
On Mon, Sep 08, 2025 at 08:13:31AM +0200, Hannes Reinecke wrote:
> > const struct cpumask *blk_mq_online_queue_affinity(void)
> > {
> > + if (housekeeping_enabled(HK_TYPE_IO_QUEUE)) {
> > + cpumask_and(&blk_hk_online_mask, cpu_online_mask,
> > + housekeeping_cpumask(HK_TYPE_IO_QUEUE));
> > + return &blk_hk_online_mask;
>
> Can you explain the use of 'blk_hk_online_mask'?
> Why is a static variable?
The blk_mq_*_queue_affinity helpers return a const struct cpumask *, the
caller doesn't need to free the return value. Because cpumask_and needs
store its result somewhere, I opted for the global static variable.
> To my untrained eye it's being recalculated every time one calls
> this function. And only the first invocation run on an empty mask,
> all subsequent ones see a populated mask.
The cpu_online_mask might change over time, it's not a static bitmap.
Thus it's necessary to update the blk_hk_online_mask. Doing some sort of
caching is certainly possible. Given that we have plenty of cpumask
logic operation in the cpu_group_evenly code path later, I am not so
sure this really makes a huge difference.
Powered by blists - more mailing lists