From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Mike Snitzer <snitzer@kernel.org>
Subject: Re: [GIT PULL] Block updates for 6.9-rc1
Date: Mon, 11 Mar 2024 19:01:39 -0600 [thread overview]
Message-ID: <9f07c344-d91f-46e0-b8b9-aa9db1d04b0a@kernel.dk> (raw)
In-Reply-To: <CAHk-=wgXZ6dE1yHK_jQmnSjbEbndyzZHC5dJNsmQYTD2K-m61w@mail.gmail.com>
On 3/11/24 6:21 PM, Linus Torvalds wrote:
> On Mon, 11 Mar 2024 at 17:02, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> Just revert that commit it for now.
>
> Done.
Thanks!
> I have to say, this is *not* some odd config here. It's literally a
> default Fedora setup with encrypted volumes.
Oh I realize that, which is why I'm so puzzled why it was broken. It's
probably THE most common laptop setup.
> So the fact that this got reported after I merged this shows a
> complete lack of testing.
Mike reviewed AND tested the whole thing, so you are wrong. I see he's
also responded with that. Why we had this fallout is as-of yet not
known, but we'll certainly figure it out.
> It also makes me suspect that you do all your performance-testing on
> something that may show great performance, but isn't perhaps the best
> thing to actually use.
I do that on things that I use, and what's being used in production.
This includes obvious the block core and bits that use it, and on the
storage front mostly nvme these days. I tested dm scalability and
performance with Mike some months ago, and md is a regular thing too. In
fact some of the little tweaks in this current series benefit the distro
configurations quite a bit, which is obviously what customers/users tend
to run. It's all being worked up through the stack.
crypt is fine and all for laptop usage, but I haven't otherwise seen it
used.
> May I suggest you start looking at encrypted volumes, and do your
> performance work on those for a while?
>
> Yes, it will suck to see the crypto overhead, but hey, it's also real
> life for real loads, so...
Honestly, my knee jerk reaction was "pfft I don't think so" as it's not
an interesting use case to me. I'd be very surprised if it wasn't all
lower hanging DM related fruits here, and maybe it's things like a
single decrypt/encrypt pipeline. Maybe that's out of necessity, maybe
it's an implementation detail that could get fixed.
That said, it certainly would be interesting to look at. But also
probably something that require rewriting it from scratch, probably as a
dm-crypt-v2 or something. Maybe? Pure handwaving.
What would make me do that is if I had to use it myself. Without that
motivation, there's not a lot of time leftover to throw at an area where
I suspect performance is perhaps Good Enough that people don't complain
about it, particularly because the use case is what it is.
--
Jens Axboe
next prev parent reply other threads:[~2024-03-12 1:01 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-10 20:30 [GIT PULL] Block updates for 6.9-rc1 Jens Axboe
2024-03-11 19:43 ` pr-tracker-bot
2024-03-11 23:50 ` Johannes Weiner
2024-03-11 23:53 ` Jens Axboe
2024-03-11 23:58 ` Linus Torvalds
2024-03-12 0:02 ` Jens Axboe
2024-03-12 0:21 ` Linus Torvalds
2024-03-12 0:28 ` Mike Snitzer
2024-03-12 1:03 ` Jens Axboe
2024-03-12 1:09 ` Christoph Hellwig
2024-03-12 1:17 ` Jens Axboe
2024-03-12 1:20 ` Linus Torvalds
2024-03-12 1:23 ` Jens Axboe
2024-03-12 1:28 ` Linus Torvalds
2024-03-12 1:37 ` Jens Axboe
2024-03-12 16:39 ` Keith Busch
2024-03-12 11:53 ` Christoph Hellwig
2024-03-12 15:25 ` Jens Axboe
2024-03-12 11:52 ` Christoph Hellwig
2024-03-12 15:22 ` Mike Snitzer
2024-03-12 16:28 ` Keith Busch
2024-03-12 21:10 ` Christoph Hellwig
2024-03-12 22:22 ` Mike Snitzer
2024-03-12 22:30 ` Christoph Hellwig
2024-03-12 22:50 ` Mike Snitzer
2024-03-12 22:58 ` Christoph Hellwig
2024-04-11 20:15 ` [PATCH for-6.10 0/2] dm: use late bio-splitting and queue_limits_set Mike Snitzer
2024-04-11 20:15 ` [PATCH for-6.10 1/2] dm-crypt: stop constraining max_segment_size to PAGE_SIZE Mike Snitzer
2024-04-12 6:11 ` Christoph Hellwig
2024-04-15 14:08 ` Mikulas Patocka
2024-04-23 7:32 ` Ming Lei
2024-04-11 20:15 ` [PATCH for-6.10 2/2] dm: use queue_limits_set Mike Snitzer
2024-04-23 7:33 ` Ming Lei
2024-03-13 13:11 ` [GIT PULL] Block updates for 6.9-rc1 Ming Lei
2024-03-12 1:01 ` Jens Axboe [this message]
2024-03-12 0:25 ` Mike Snitzer
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=9f07c344-d91f-46e0-b8b9-aa9db1d04b0a@kernel.dk \
--to=axboe@kernel.dk \
--cc=hannes@cmpxchg.org \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=snitzer@kernel.org \
--cc=torvalds@linux-foundation.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