Hannes, > On Jul 21, 2016, at 15:37, Hannes Reinecke <hare@xxxxxxx> wrote: > > On 07/21/2016 08:01 AM, Hannes Reinecke wrote: >> On 07/21/2016 07:54 AM, Christoph Hellwig wrote: >>> On Tue, Jul 19, 2016 at 04:02:56PM +0200, Hannes Reinecke wrote: >>>> Some devices (most notably SMR drives) support only >>>> one I/O stream eg for ensuring ordered I/O submission. >>>> This patch adds a new block queue flag >>>> 'BLK_QUEUE_SINGLE' to support these devices. >>> >>> We'll need a blk-mq implementation of this flag as well before it can >>> be merged. >>> >> Yes, indeed. Will be fixed for the next round of submissions. >> > Hmm. > Looking closer do I _really_ need that for blk-mq? > From my understanding any hctx can only run on one dedicated cpu, to > which the hctx is bound. > So if we only have one CPU serving that hctx how can we have several > concurrent calls to queue_rq() here? Ex: an application with 2 threads running on different CPUs, with both threads writing to the same sequential zone with a proper mutual exclusion to ensure sequential write order at the application level. For this example, each thread requests will end up in a different hw queue (hctx), and a single CPU serving each hctx may not result in an overall in-order delivery to the disk. So we need to ensure that all requests for a sequential zone end up in the same hctx, which I think means simply that we need to allow only a single queue for a ZBC device. If one day we get a fast SSD supporting ZBC/ZAC commands, this may impact performance though... I may be completely wrong about this though. Cheers. ------------------------ Damien Le Moal, Ph.D. Sr. Manager, System Software Group, HGST Research, HGST, a Western Digital brand Damien.LeMoal@xxxxxxxx (+81) 0466-98-3593 (ext. 513593) 1 kirihara-cho, Fujisawa, Kanagawa, 252-0888 Japan www.hgst.com Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html