[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aTMgS0njg-R-T0pT@kbusch-mbp>
Date: Fri, 5 Dec 2025 11:11:23 -0700
From: Keith Busch <kbusch@...nel.org>
To: Mohamed Khalfella <mkhalfella@...estorage.com>
Cc: Bart Van Assche <bvanassche@....org>,
Chaitanya Kulkarni <kch@...dia.com>, Christoph Hellwig <hch@....de>,
Jens Axboe <axboe@...nel.dk>, Sagi Grimberg <sagi@...mberg.me>,
Casey Chen <cachen@...estorage.com>,
Yuanyuan Zhong <yzhong@...estorage.com>,
Hannes Reinecke <hare@...e.de>, Ming Lei <ming.lei@...hat.com>,
Waiman Long <llong@...hat.com>, Hillf Danton <hdanton@...a.com>,
linux-nvme@...ts.infradead.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] block: Use RCU in blk_mq_[un]quiesce_tagset()
instead of set->tag_list_lock
On Fri, Dec 05, 2025 at 08:39:26AM -0800, Mohamed Khalfella wrote:
> Why sychronize_rcu() is intolerable in this blk_mq_del_queue_tag_set()?
> This code is not performance sensitive, right?
synchronize_rcu() gets expensive on servers with many CPUs. While this
is not a fast path, I think adding it here would still be harmful, if
only just to testing when devices are frequently created and deleted.
> Looking at the code again, I _think_ synchronize_rcu() along with
> INIT_LIST_HEAD(&q->tag_set_list) can be deleted. I do not see usecase
> where "q" is re-added to a tagset after it is deleted from one.
> Also, "q" is freed in blk_free_queue() after end of RCU grace period.
I think you could skip the synchronize since the queue's memory free is
done in blk_free_queue_rcu from a call_rcu() callback.
Powered by blists - more mailing lists