Re: [RFC PATCH v2 2/4] blk-cgroup: use a request_queue rhashtable for blkg lookup
Christoph Hellwig <[email protected]>
| Newsgroups | org.kernel.vger.linux-block,dev.linux.lists.dm-devel,dev.linux.lists.gfs2,dev.linux.lists.nvdimm,dev.linux.lists.virtualization,org.kernel.vger.cgroups,org.kernel.vger.linux-bcache,org.kernel.vger.linux-doc,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-raid,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Aug 14, 2026 at 03:50:04PM +0800, Yu Kuai wrote: > > Are these fast path operations? Otherwise we can walk all rhashtable > > entries without an extra list, but it might be slower. > > All users are from sysfs/cgroupfs API, I think they can be considered slow path, > however currently spinlock is held in these procedures, I think it's better to > convert them to blkg_lookup based iterate after spinlock is converted to the > blkcg_mutex. Sounds good. Maybe put that into the commit log? > > Please add must_hold and/or lockdep annotations for this instead of just > > a comment. > > > > Also maybe mention that this does not acquire a reference and the caller > > must already hold one? > > Perhaps it's more accurate that the blkg is pinned by IO or caller already > hold one? Sounds good.