| Message ID | 1468936978-9124-2-git-send-email-hare@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 7/19/16 23:02, 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. > > Signed-off-by: Hannes Reinecke <hare@suse.de> > --- > block/blk-core.c | 2 ++ > include/linux/blkdev.h | 2 ++ > 2 files changed, 4 insertions(+) Reviewed-by: Damien Le Moal <damien.lemoal@hgst.com> Tested-by: Damien Le Moal <damien.lemoal@hgst.com>
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. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Cheers, Hannes
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? Cheers, Hannes
Hannes, > On Jul 21, 2016, at 15:37, Hannes Reinecke <hare@suse.de> 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@hgst.com (+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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 21, 2016 at 08:37:10AM +0200, Hannes Reinecke wrote: > 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. That's not the case. A hctx exists for each hardware queue, and a CPU must be mapped to a hctx. So if you have less hctx than CPUs (e.g. just one) you have multiple CPUs that could submit on a hctx. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/block/blk-core.c b/block/blk-core.c index 4bcf30a..ff08d77 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -320,6 +320,8 @@ inline void __blk_run_queue_uncond(struct request_queue *q) * number of active request_fn invocations such that blk_drain_queue() * can wait until all these request_fn calls have finished. */ + if (blk_queue_single(q) && q->request_fn_active) + return; q->request_fn_active++; q->request_fn(q); q->request_fn_active--; diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index c351444..2f7775a 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -539,6 +539,7 @@ struct request_queue { #define QUEUE_FLAG_WC 23 /* Write back caching */ #define QUEUE_FLAG_FUA 24 /* device supports FUA writes */ #define QUEUE_FLAG_FLUSH_NQ 25 /* flush not queueuable */ +#define QUEUE_FLAG_SINGLE 26 /* single-threaded submission only */ #define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) | \ (1 << QUEUE_FLAG_STACKABLE) | \ @@ -628,6 +629,7 @@ static inline void queue_flag_clear(unsigned int flag, struct request_queue *q) #define blk_queue_discard(q) test_bit(QUEUE_FLAG_DISCARD, &(q)->queue_flags) #define blk_queue_secdiscard(q) (blk_queue_discard(q) && \ test_bit(QUEUE_FLAG_SECDISCARD, &(q)->queue_flags)) +#define blk_queue_single(q) test_bit(QUEUE_FLAG_SINGLE, &(q)->queue_flags) #define blk_noretry_request(rq) \ ((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \
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. Signed-off-by: Hannes Reinecke <hare@suse.de> --- block/blk-core.c | 2 ++ include/linux/blkdev.h | 2 ++ 2 files changed, 4 insertions(+)