Re: [PATCH v2] Support for write stream IDs

[Martin K. Petersen]

>>>>> "Jens" == Jens Axboe <axboe@xxxxxx> writes:

Jens> This wont solve the problem of devices having too few streams. But
Jens> it'll work regardless, we'll just have to push them separately to
Jens> do that. It's not an easy problem for them either, resource
Jens> constraints on the device side could exclude supporting as many
Jens> streams as we would ideally want.

But they already have to manage *every* other resource that way: Read
cache, write cache, flash channels, open zones on ZAC/ZBC. If they run
out of memory and have to internally close one stream context to open
another that's their business. If the concurrent ID count is low,
performance their particular widgets is going to suck for some
applications and people will avoid them. Boo hoo.

I'm super happy the SSD industry (well, the market) came to its senses
and abolished all the outrageous demands put on the I/O stack to
overcome erase block size and write amplification issues. Now all that's
a solved problem and we can move on.

Next problem child was the host managed zoned disk madness. Yet another
device implementation headache that suddenly requires us to reinvent
filesystems and the entire I/O stack.

Next in the pipeline is the stream ID stuff. Which once again puts the
burden on us to overcome device implementation issues and misunderstands
how operating systems work.

There are two fundamental problems:

 - The standards are developed by device vendors with little to no input
   from the OS vendors

 - The standards proposals are written, edited, and declared complete
   before anybody actually tries to implement them

That's how we end up with all these lame duck spec extensions that are
device implementation-specific and impossible to use generically.

I scream as loudly as I can. But I am but one voice in a sea of device
vendors. And unless we Linux developers start pushing back in unison
we'll end up in a quagmire of epic proportions.

Jens> In some ways I get it, you have to start somewhere. The current
Jens> proposal is useful for _some_ cases, it's not great for
Jens> everything. As long as it can be expanded to support as many
Jens> streams as we would want, then it would work. It's (again) a bit
Jens> of a chicken and egg problem. We need to make some progress, or
Jens> the whole thing is going to go away. And I think that'd be a
Jens> shame, since there's definitely merit to passing these lifetime
Jens> hints to the device.

The problem is that once these things end up in the standards, the CDB
fields are gone. And if the clunky intermediate stuff is "good enough"
then the motivation to fix things properly goes away.

There are many, many reasons why stream IDs are a good thing. Above and
beyond what the current proposals want. The notion of tagging is a much
better abstraction than bootiness and guessing a percentage for how
sequential future accesses might be. It's a simple, clean interface that
the device--regardless of media type and implementation--can benefit
from.

-- 
Martin K. Petersen	Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/