Re: [PATCH 3/3] block/mq-deadline: Disable I/O prioritization in certain cases

[Christoph Hellwig <hch@lst.de>]

On Wed, Dec 13, 2023 at 08:41:32AM -0800, Jaegeuk Kim wrote:
> I don't have any
> concern to keep the same ioprio on writes, since handheld devices are mostly
> sensitive to reads. So, if you have other use-cases using zoned writes which
> require different ioprio on writes, I think you can suggest a knob to control
> it by users.

Get out of your little handheld world.  In Linux we need a generally usable
I/O stack, and any feature exposed by the kernel and will be used quite
differently than you imagine.

Just like people will add reordering to the I/O stack that's not there
right now (in addition to the ones your testing doesn't hit).  That
doensn't mean we should avoid them - you genereally get better performance
by not reordering without a good reason (like thotting), but especially
in error handling paths or resource constrained environment they will
hapen all over.  We've had this whole discussion with the I/O barriers
that did not work for exactly the same reasons.

> 
> > 
> > > it is essential to place the data per file to get better bandwidth. And for
> > > NAND-based storage, filesystem is the right place to deal with the more efficient
> > > garbage collecion based on the known data locations.
> > 
> > And that works perfectly fine match for zone append.
> 
> How that works, if the device gives random LBAs back to the adjacent data in
> a file? And, how to make the LBAs into the sequential ones back?

Why would your device pick random LBAs?  If you send a zone append to
zone it will be written at the write pointer, which is absolutely not
random.  All I/O written in a single write is going to be sequential,
so just like for all other devices doing large sequential writes is
important.  Multiple writes can get reordered, but if you havily hit
the same zone you'd get the same effect in the file system allocator
too.

> Sorry, I needed to stop reading here, as you're totally biased. This is not
> the case in JEDEC, as Bart spent multiple years to synchronize the technical
> benefitcs that we've seen across UFS vendors as well as OEMs.

*lol*  There is no more fucked up corporate pressure standard committee
than the storage standards in JEDEC.  That's why not one actually takes
them seriously.