From: Ming Lei <ming.lei@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Yu Kuai <yukuai3@huawei.com>
Subject: Re: [PATCH 6/6] blk-mq: manage hctx map via xarray
Date: Wed, 2 Mar 2022 17:53:44 +0800 [thread overview]
Message-ID: <Yh8+qA4p6EWGFbtG@T590> (raw)
In-Reply-To: <Yh8pwiR5DWC9ELDD@infradead.org>
On Wed, Mar 02, 2022 at 12:24:34AM -0800, Christoph Hellwig wrote:
> On Wed, Mar 02, 2022 at 10:06:04AM +0800, Ming Lei wrote:
> > I did considered xa_for_each(), but it requires rcu read lock.
>
> No, I doesn't. It just takes a RCU lock internally.
OK.
>
> > Also queue_for_each_hw_ctx() is supposed to not run in fast path,
> > meantime xa_load() is lightweight enough too, so repeated xa_load()
> > is fine here.
>
> I'd rather have the clarity of the proper iterators.
Another point is that 'unsigned long *' is passed to xa_find() as index.
However, almost all users of queue_for_each_hw_ctx() defines hctx index
as 'unsigned int'.
If we switch to xa_for_each(), the type of hctx index needs to be changed
to 'unsigned long' for every queue_for_each_hw_ctx(). But xa_load()
needn't such change.
Also from user viewpoint, looks 'unsigned long' change for hctx index is
still a bit confusing, IMO.
Thanks,
Ming
next prev parent reply other threads:[~2022-03-02 9:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-28 9:04 [PATCH 0/6] blk-mq: update_nr_hw_queues related improvement & bugfix Ming Lei
2022-02-28 9:04 ` [PATCH 1/6] blk-mq: figure out correct numa node for hw queue Ming Lei
2022-03-01 13:30 ` Christoph Hellwig
2022-03-01 19:19 ` John Garry
2022-03-02 1:47 ` Ming Lei
2022-03-02 9:02 ` John Garry
2022-03-02 9:22 ` Ming Lei
2022-03-02 10:11 ` John Garry
2022-02-28 9:04 ` [PATCH 2/6] blk-mq: simplify reallocation of hw ctxs a bit Ming Lei
2022-03-01 13:30 ` Christoph Hellwig
2022-02-28 9:04 ` [PATCH 3/6] blk-mq: re-config poll after queue map is changed Ming Lei
2022-03-01 13:31 ` Christoph Hellwig
2022-02-28 9:04 ` [PATCH 4/6] block: mtip32xx: don't touch q->queue_hw_ctx Ming Lei
2022-03-01 13:32 ` Christoph Hellwig
2022-02-28 9:04 ` [PATCH 5/6] blk-mq: add helper of blk_mq_get_hctx to retrieve hctx via its index Ming Lei
2022-03-01 13:33 ` Christoph Hellwig
2022-02-28 9:04 ` [PATCH 6/6] blk-mq: manage hctx map via xarray Ming Lei
2022-02-28 17:36 ` kernel test robot
2022-02-28 17:57 ` kernel test robot
2022-03-01 9:08 ` Ming Lei
2022-03-01 13:37 ` Christoph Hellwig
2022-03-02 2:06 ` Ming Lei
2022-03-02 8:24 ` Christoph Hellwig
2022-03-02 9:53 ` Ming Lei [this message]
2022-03-02 9:59 ` Christoph Hellwig
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=Yh8+qA4p6EWGFbtG@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=yukuai3@huawei.com \
/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