From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: Ming Lei <ming.lei@redhat.com>,
linux-block@vger.kernel.org, Ulf Hansson <ulf.hansson@linaro.org>,
linux-mmc@vger.kernel.org
Subject: Re: [PATCH 2/2] blk-mq: ensure a q_usage_counter reference is held when splitting bios
Date: Fri, 12 Jan 2024 06:44:49 +0100 [thread overview]
Message-ID: <20240112054449.GA6829@lst.de> (raw)
In-Reply-To: <1d682398-9922-404b-ac50-2fb292793ddb@kernel.dk>
On Thu, Jan 11, 2024 at 01:06:43PM -0700, Jens Axboe wrote:
> Something like this? Not super pretty with the duplication, but...
> Should suffice for a fix, and then we can refactor it on top of that.
> ioprio is inherited when cloning, so we don't need to do that post the
> split.
Yes, this could work. It'll get worse with anything we need to do under
q_usage_counter counter, though. I mean, it is a perpcu_counter, which
should be really light-weight compared to all the other stuff you do.
I'd really love to see numbers that show it matters.
> For the bounce side, how would these settings change at runtime?
Well, we don't really prevent any setting from changing at runtime.
But yes, neither mmc nor the few scsi drivers using it seems to do
any runtime re-configuration.
> Should
> be set at init time and then never change. And agree would be so nice to
> kill that code...
I wish we could see some more folks from the mmc maintainers to do
proper scatterlist (or bio/request) kmap helpers. The scsi drivers
could easily piggy back on that or just be disabled for HIGHMEM configs.
next parent reply other threads:[~2024-01-12 5:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1d682398-9922-404b-ac50-2fb292793ddb@kernel.dk>
2024-01-12 5:44 ` Christoph Hellwig [this message]
2024-01-12 14:22 ` [PATCH 2/2] blk-mq: ensure a q_usage_counter reference is held when splitting bios Jens Axboe
2024-01-12 14:25 ` Christoph Hellwig
2024-01-12 16:10 ` Jens Axboe
2024-01-15 11:20 ` Ulf Hansson
2024-01-22 7:34 ` mmc vs highmem, was: " Christoph Hellwig
2024-01-22 9:26 ` Arnd Bergmann
2024-01-22 13:39 ` Christoph Hellwig
2024-01-22 14:57 ` Arnd Bergmann
2024-01-23 9:11 ` Christoph Hellwig
2024-01-24 11:59 ` Arnd Bergmann
2024-01-24 12:33 ` Linus Walleij
2024-01-24 12:54 ` Arnd Bergmann
2024-01-24 13:16 ` Linus Walleij
2024-01-24 14:14 ` Arnd Bergmann
2024-01-24 12:45 ` Arnd Bergmann
2024-01-24 13:49 ` Linus Walleij
2024-01-24 16:35 ` Arnd Bergmann
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=20240112054449.GA6829@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=ulf.hansson@linaro.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).