Re: [GIT PULL] Block updates for 6.9-rc1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/11/24 6:21 PM, Linus Torvalds wrote:
> On Mon, 11 Mar 2024 at 17:02, Jens Axboe <axboe@xxxxxxxxx> 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





[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux