On 03/06/2016 03:03 PM, Martin K. Petersen wrote: >>>>>> "Andreas" == Andreas Dilger <adilger@xxxxxxxxx> writes: > > Andreas, > > Andreas> What are your thoughts on reserving a small number of the > Andreas> stream ID values for filesystem metadata (e.g. the first 31 > Andreas> since 0 == unused)? > > The stream ID address space might be 16-bit but the devices currently > being discussed can only handle a few concurrently open streams (4, 8, > 16). > So I can't for the life of me understand what is the use of all this. If what Jens said at beginning for data grouping than what is it at all got to do with open and close of anything? Really? Does it make any sense to you? I mean with multy-queue with HW channels for every CPU, parallel IO, and poling because even interrupts are too slow, you want me to cram everything and serialize it on 4 open/close streams? Either I'm completely missing something. Or please please explain what is going on. How does 4 stream make any sense in today's NvME HW? How does open/close anything make any sense? On the surface it looks like someone is smoking something really bad. > Discussions are ongoing about whether the devices should be able to > implicitly close a stream based on LRU or something similar when the hw > max is reached. But as it stands you have to explicitly close an > existing stream with a separate command when the max is reached. > Otherwise a write with a previously unused stream ID will fail. > ?? (see smoking above ;-) ) > I.e. there is a significant cost to switching between stream IDs and > thus I am afraid the current stuff isn't well suited to having a fine > grained tagging approach like the one you are proposing. > So again who cares for anything that hurts performance? Why would I want to use anything that has "significant cost" at all? Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
