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

[Jaegeuk Kim <jaegeuk@kernel.org>]

On 12/13, Christoph Hellwig wrote:
> On Tue, Dec 12, 2023 at 11:03:06AM -0800, Jaegeuk Kim wrote:
> > As one of users of zoned devices, I disagree this is a broken model,
> 
> So you think that chasing potential for reordering all over the I/O
> stack in perpetualality, including obscure error handling paths and
> disabling features intentended to throttle and delay I/O (like
> ioprio and cgroups) is not a broken model?

As of now, we don't see any reordering issue except this. 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.

> 
> > 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?

> 
> > That's why all the flash
> > storage vendors adopted it in the JEDEC.
> 
> Everyone sucking up to Google to place their product in Android, yes..

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.

> 
> 
> > Agreed that zone append is nice, but
> > IMO, it's not practical for production.
> 
> You've delivered exactly zero arguments for that.