Skip to contentSkip to conversation

Add plug based request allocation batching

RFC PATCH Superseded Jens Axboe 2 participants 8 messages Oct 6, 2021

Subsystems (2)

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Jens Axboe

author maintainer
#0 lore raw

cover Add plug based request allocation batching

Hi,

Even if the caller knows that N requests will be submitted, we still have to go all the way to tag allocation for each one. That's somewhat inefficient, when we could just grab as many tags as we need initially instead.

This small series allows request caching in the blk_plug. We add a new helper for passing in how many requests we expect to submit, blk_start_plug_nr_ios(), and then we can use that information to populate the cache on the first request allocation. Subsequent queue attempts can then just grab a pre-allocated request out of the cache rather than go into the tag allocation again.

This brings single core performance on my setup from:

sudo taskset -c 0,16 t/io_uring -b512 -d128 -s32 -c32 -p1 -F1 -B1 -n2 /dev/nvme1n1 /dev/nvme2n1 Added file /dev/nvme1n1 (submitter 0)
Added file /dev/nvme2n1 (submitter 1)
polled=1, fixedbufs=1, register_files=1, buffered=0, QD=128
Engine=io_uring, sq_ring=128, cq_ring=256
submitter=0, tid=1206
submitter=1, tid=1207
IOPS=5806400, BW=2835MiB/s, IOS/call=32/32, inflight=(77 32)
IOPS=5860352, BW=2861MiB/s, IOS/call=32/31, inflight=(102 128)
IOPS=5844800, BW=2853MiB/s, IOS/call=32/32, inflight=(102 32)

to:

taskset -c 0,16 t/io_uring -b512 -d128 -s32 -c32 -p1 -F1 -B1 -n2 /dev/nvme1n1 /dev/nvme2n1 Added file /dev/nvme1n1 (submitter 0)
Added file /dev/nvme2n1 (submitter 1)
polled=1, fixedbufs=1, register_files=1, buffered=0, QD=128
Engine=io_uring, sq_ring=128, cq_ring=256
submitter=0, tid=1220
submitter=1, tid=1221
IOPS=6061248, BW=2959MiB/s, IOS/call=32/31, inflight=(114 82)
IOPS=6100672, BW=2978MiB/s, IOS/call=32/31, inflight=(128 128)
IOPS=6082496, BW=2969MiB/s, IOS/call=32/32, inflight=(77 38)

which is about a 4-5% improvement in single core performance. Looking at profiles, we're spending _less_ time in sbitmap even though we're doing more work.

Signature · 1 line
Jens Axboe
author maintainer
#1 lore raw

PATCH 1/3 block: bump max plugged deferred size from 16 to 32

Particularly for NVMe with efficient deferred submission for many requests, there are nice benefits to be seen by bumping the default max plug count from 16 to 32. This is especially true for virtualized setups, where the submit part is more expensive. But can be noticed even on native hardware.

Reduce the multiple queue factor from 4 to 2, since we're changing the default size.

---
 block/blk-mq.c         | 4 ++--
 include/linux/blkdev.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)
block/blk-mq.c +2 -2
index a40c94505680..5327abbefbab 100644
@@ -2145,14 +2145,14 @@ static void blk_add_rq_to_plug(struct blk_plug *plug, struct request *rq)
 }
 
 /*
- * Allow 4x BLK_MAX_REQUEST_COUNT requests on plug queue for multiple
+ * Allow 2x BLK_MAX_REQUEST_COUNT requests on plug queue for multiple
  * queues. This is important for md arrays to benefit from merging
  * requests.
  */
 static inline unsigned short blk_plug_max_rq_count(struct blk_plug *plug)
 {
 	if (plug->multiple_queues)
-		return BLK_MAX_REQUEST_COUNT * 4;
+		return BLK_MAX_REQUEST_COUNT * 2;
 	return BLK_MAX_REQUEST_COUNT;
 }
 
include/linux/blkdev.h +1 -1
index b19172db7eef..534298ac73cc 100644
@@ -727,7 +727,7 @@ struct blk_plug {
 	bool multiple_queues;
 	bool nowait;
 };
-#define BLK_MAX_REQUEST_COUNT 16
+#define BLK_MAX_REQUEST_COUNT 32
 #define BLK_PLUG_FLUSH_SIZE (128 * 1024)
 
 struct blk_plug_cb;
Signature · 1 line
2.33.0
#2 lore raw

Re: [PATCH 1/3] block: bump max plugged deferred size from 16 to 32

Quoted 41 lines · Jens Axboe

Particularly for NVMe with efficient deferred submission for many requests, there are nice benefits to be seen by bumping the default max plug count from 16 to 32. This is especially true for virtualized setups, where the submit part is more expensive. But can be noticed even on native hardware.

Reduce the multiple queue factor from 4 to 2, since we're changing the default size.

---
  block/blk-mq.c         | 4 ++--
  include/linux/blkdev.h | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)
block/blk-mq.c +2 -2
index a40c94505680..5327abbefbab 100644
@@ -2145,14 +2145,14 @@ static void blk_add_rq_to_plug(struct blk_plug *plug, struct request *rq)
  }
 
  /*
- * Allow 4x BLK_MAX_REQUEST_COUNT requests on plug queue for multiple
+ * Allow 2x BLK_MAX_REQUEST_COUNT requests on plug queue for multiple
   * queues. This is important for md arrays to benefit from merging
   * requests.
   */
  static inline unsigned short blk_plug_max_rq_count(struct blk_plug *plug)
  {
  	if (plug->multiple_queues)
-		return BLK_MAX_REQUEST_COUNT * 4;
+		return BLK_MAX_REQUEST_COUNT * 2;
  	return BLK_MAX_REQUEST_COUNT;
  }
 
include/linux/blkdev.h +0 -0
index b19172db7eef..534298ac73cc 100644

include/linux/blkdev.h struct blk_plug { · line 733

Quoted 8 lines
include/linux/blkdev.h +1 -1
@@ -727,7 +727,7 @@ struct blk_plug {
  	bool multiple_queues;
  	bool nowait;
  };
-#define BLK_MAX_REQUEST_COUNT 16
+#define BLK_MAX_REQUEST_COUNT 32
  #define BLK_PLUG_FLUSH_SIZE (128 * 1024)
 
  struct blk_plug_cb;

Since BLK_MAX_REQUEST_COUNT is only used inside the block layer core but not by any block driver, can it be moved from include/linux/blkdev.h into block/blk-mq.h?

Thanks,

Bart.

author maintainer
#3 lore raw

Re: [PATCH 1/3] block: bump max plugged deferred size from 16 to 32

Quoted 49 lines · Bart Van Assche
Quoted 48 lines · Jens Axboe

Particularly for NVMe with efficient deferred submission for many requests, there are nice benefits to be seen by bumping the default max plug count from 16 to 32. This is especially true for virtualized setups, where the submit part is more expensive. But can be noticed even on native hardware.

Reduce the multiple queue factor from 4 to 2, since we're changing the default size.

---
  block/blk-mq.c         | 4 ++--
  include/linux/blkdev.h | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)
block/blk-mq.c +2 -2
index a40c94505680..5327abbefbab 100644
@@ -2145,14 +2145,14 @@ static void blk_add_rq_to_plug(struct blk_plug *plug, struct request *rq)
  }
 
  /*
- * Allow 4x BLK_MAX_REQUEST_COUNT requests on plug queue for multiple
+ * Allow 2x BLK_MAX_REQUEST_COUNT requests on plug queue for multiple
   * queues. This is important for md arrays to benefit from merging
   * requests.
   */
  static inline unsigned short blk_plug_max_rq_count(struct blk_plug *plug)
  {
  	if (plug->multiple_queues)
-		return BLK_MAX_REQUEST_COUNT * 4;
+		return BLK_MAX_REQUEST_COUNT * 2;
  	return BLK_MAX_REQUEST_COUNT;
  }
 
include/linux/blkdev.h +1 -1
index b19172db7eef..534298ac73cc 100644
@@ -727,7 +727,7 @@ struct blk_plug {
  	bool multiple_queues;
  	bool nowait;
  };
-#define BLK_MAX_REQUEST_COUNT 16
+#define BLK_MAX_REQUEST_COUNT 32
  #define BLK_PLUG_FLUSH_SIZE (128 * 1024)
 
Quoted 5 lines

include/linux/blkdev.h struct blk_plug { · line 733

Quoted 1 line
include/linux/blkdev.h +0 -0
  struct blk_plug_cb;

Since BLK_MAX_REQUEST_COUNT is only used inside the block layer core but not by any block driver, can it be moved from include/linux/blkdev.h into block/blk-mq.h?

Good point, I'll move it in there as part of the patch.

Signature · 1 line
Jens Axboe
author maintainer
#4 lore raw

PATCH 2/3 block: pre-allocate requests if plug is started and is a batch

In reply to Jens Axboe

The caller typically has a good (or even exact) idea of how many requests it needs to submit. We can make the request/tag allocation a lot more efficient if we just allocate N requests/tags upfront when we queue the first bio from the batch.

Provide a new plug start helper that allows the caller to specify how many IOs are expected. This sets plug->nr_ios, and we can use that for smarter request allocation. The plug provides a holding spot for requests, and request allocation will check it before calling into the normal request allocation path.

The blk_finish_plug() is called, check if there are unused requests and free them. This should not happen in normal operations. The exception is if we get merging, then we may be left with requests that need freeing when done.

This raises the per-core performance on my setup from ~5.8M to ~6.1M IOPS.

---
 block/blk-core.c          | 47 +++++++++++++++-----------
 block/blk-mq.c            | 70 ++++++++++++++++++++++++++++++++-------
 block/blk-mq.h            |  5 +++
 include/linux/blk-mq.h    |  5 ++-
 include/linux/blk_types.h |  1 +
 include/linux/blkdev.h    | 15 ++++++++-
 6 files changed, 110 insertions(+), 33 deletions(-)
block/blk-core.c +28 -19
index d83e56b2f64e..9b8c70670190 100644
@@ -1624,6 +1624,31 @@ int kblockd_mod_delayed_work_on(int cpu, struct delayed_work *dwork,
 }
 EXPORT_SYMBOL(kblockd_mod_delayed_work_on);
 
+void blk_start_plug_nr_ios(struct blk_plug *plug, unsigned short nr_ios)
+{
+	struct task_struct *tsk = current;
+
+	/*
+	 * If this is a nested plug, don't actually assign it.
+	 */
+	if (tsk->plug)
+		return;
+
+	INIT_LIST_HEAD(&plug->mq_list);
+	plug->cached_rq = NULL;
+	plug->nr_ios = min_t(unsigned short, nr_ios, BLK_MAX_REQUEST_COUNT);
+	plug->rq_count = 0;
+	plug->multiple_queues = false;
+	plug->nowait = false;
+	INIT_LIST_HEAD(&plug->cb_list);
+
+	/*
+	 * Store ordering should not be needed here, since a potential
+	 * preempt will imply a full memory barrier
+	 */
+	tsk->plug = plug;
+}
+
 /**
  * blk_start_plug - initialize blk_plug and track it inside the task_struct
  * @plug:	The &struct blk_plug that needs to be initialized
@@ -1649,25 +1674,7 @@ EXPORT_SYMBOL(kblockd_mod_delayed_work_on);
  */
 void blk_start_plug(struct blk_plug *plug)
 {
-	struct task_struct *tsk = current;
-
-	/*
-	 * If this is a nested plug, don't actually assign it.
-	 */
-	if (tsk->plug)
-		return;
-
-	INIT_LIST_HEAD(&plug->mq_list);
-	INIT_LIST_HEAD(&plug->cb_list);
-	plug->rq_count = 0;
-	plug->multiple_queues = false;
-	plug->nowait = false;
-
-	/*
-	 * Store ordering should not be needed here, since a potential
-	 * preempt will imply a full memory barrier
-	 */
-	tsk->plug = plug;
+	blk_start_plug_nr_ios(plug, 1);
 }
 EXPORT_SYMBOL(blk_start_plug);
 
@@ -1719,6 +1726,8 @@ void blk_flush_plug_list(struct blk_plug *plug, bool from_schedule)
 
 	if (!list_empty(&plug->mq_list))
 		blk_mq_flush_plug_list(plug, from_schedule);
+	if (unlikely(!from_schedule && plug->cached_rq))
+		blk_mq_free_plug_rqs(plug);
 }
 
 /**
block/blk-mq.c +58 -12

126 lines not on this page · raw message

block/blk-mq.h +5 -0
index 171e8cdcff54..5da970bb8865 100644
@@ -125,6 +125,7 @@ extern int __blk_mq_register_dev(struct device *dev, struct request_queue *q);
 extern int blk_mq_sysfs_register(struct request_queue *q);
 extern void blk_mq_sysfs_unregister(struct request_queue *q);
 extern void blk_mq_hctx_kobj_init(struct blk_mq_hw_ctx *hctx);
+void blk_mq_free_plug_rqs(struct blk_plug *plug);
 
 void blk_mq_release(struct request_queue *q);
 
@@ -152,6 +153,10 @@ struct blk_mq_alloc_data {
 	unsigned int shallow_depth;
 	unsigned int cmd_flags;
 
+	/* allocate multiple requests/tags in one go */
+	unsigned int nr_tags;
+	struct request **cached_rq;
+
 	/* input & output parameter */
 	struct blk_mq_ctx *ctx;
 	struct blk_mq_hw_ctx *hctx;
include/linux/blk-mq.h +4 -1
index 75d75657df21..0e941f217578 100644
@@ -90,7 +90,10 @@ struct request {
 	struct bio *bio;
 	struct bio *biotail;
 
-	struct list_head queuelist;
+	union {
+		struct list_head queuelist;
+		struct request *rq_next;
+	};
 
 	/*
 	 * The hash is used inside the scheduler, and killed once the
include/linux/blk_types.h +1 -0
index 3b967053e9f5..4b2006ec8bf2 100644
@@ -22,6 +22,7 @@ struct bio_crypt_ctx;
 
 struct block_device {
 	sector_t		bd_start_sect;
+	sector_t		bd_nr_sectors;
 	struct disk_stats __percpu *bd_stats;
 	unsigned long		bd_stamp;
 	bool			bd_read_only;	/* read-only policy */
include/linux/blkdev.h +14 -1
index 534298ac73cc..39b58b223f84 100644
@@ -722,10 +722,17 @@ extern void blk_set_queue_dying(struct request_queue *);
  */
 struct blk_plug {
 	struct list_head mq_list; /* blk-mq requests */
-	struct list_head cb_list; /* md requires an unplug callback */
+
+	/* if ios_left is > 1, we can batch tag/rq allocations */
+	struct request *cached_rq;
+	unsigned short nr_ios;
+
 	unsigned short rq_count;
+
 	bool multiple_queues;
 	bool nowait;
+
+	struct list_head cb_list; /* md requires an unplug callback */
 };
 #define BLK_MAX_REQUEST_COUNT 32
 #define BLK_PLUG_FLUSH_SIZE (128 * 1024)
@@ -740,6 +747,7 @@ struct blk_plug_cb {
 extern struct blk_plug_cb *blk_check_plugged(blk_plug_cb_fn unplug,
 					     void *data, int size);
 extern void blk_start_plug(struct blk_plug *);
+extern void blk_start_plug_nr_ios(struct blk_plug *, unsigned short);
 extern void blk_finish_plug(struct blk_plug *);
 extern void blk_flush_plug_list(struct blk_plug *, bool);
 
@@ -774,6 +782,11 @@ long nr_blockdev_pages(void);
 struct blk_plug {
 };
 
+static inline void blk_start_plug_nr_ios(struct blk_plug *plug,
+					 unsigned short nr_ios)
+{
+}
+
 static inline void blk_start_plug(struct blk_plug *plug)
 {
 }
Signature · 1 line
2.33.0
#5 lore raw

Re: [PATCH 2/3] block: pre-allocate requests if plug is started and is a batch

include/linux/blk_types.h struct bio_crypt_ctx; · line 28

Quoted 12 lines · Jens Axboe
include/linux/blk_types.h +1 -0
index 3b967053e9f5..4b2006ec8bf2 100644
@@ -22,6 +22,7 @@ struct bio_crypt_ctx;
 
  struct block_device {
  	sector_t		bd_start_sect;
+	sector_t		bd_nr_sectors;
  	struct disk_stats __percpu *bd_stats;
  	unsigned long		bd_stamp;
  	bool			bd_read_only;	/* read-only policy */

Hmm ... I can't find any code in this patch that sets bd_nr_sectors? Did I perhaps overlook something?

Thanks,

Bart.

author maintainer
#6 lore raw

Re: [PATCH 2/3] block: pre-allocate requests if plug is started and is a batch

Quoted 7 lines · Bart Van Assche
Quoted 6 lines · Jens Axboe
include/linux/blk_types.h +0 -0
index 3b967053e9f5..4b2006ec8bf2 100644
@@ -22,6 +22,7 @@ struct bio_crypt_ctx;
 
Quoted 9 lines

include/linux/blk_types.h struct bio_crypt_ctx; · line 28

Quoted 6 lines
include/linux/blk_types.h +1 -0
  struct block_device {
  	sector_t		bd_start_sect;
+	sector_t		bd_nr_sectors;
  	struct disk_stats __percpu *bd_stats;
  	unsigned long		bd_stamp;
  	bool			bd_read_only;	/* read-only policy */

Hmm ... I can't find any code in this patch that sets bd_nr_sectors? Did I perhaps overlook something?

Good eye - nope, that's from a different patch! Looks like it got folded in by mistake... I'll fix it, thanks Bart.

Signature · 1 line
Jens Axboe
author maintainer
#7 lore raw

PATCH 3/3 io_uring: inform block layer of how many requests we are submitting

In reply to Jens Axboe

The block layer can use this knowledge to make smarter decisions on how to handle the request, if it knows that N more may be coming. Switch to using blk_start_plug_nr_ios() to pass in that information.

---
 fs/io_uring.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
fs/io_uring.c +4 -1
index 62dc128e9b6b..c35b0f230be8 100644
@@ -314,6 +314,8 @@ struct io_submit_state {
 	bool			plug_started;
 	bool			need_plug;
 
+	unsigned short		submit_nr;
+
 	/*
 	 * Batch completion logic
 	 */
@@ -7035,7 +7037,7 @@ static int io_init_req(struct io_ring_ctx *ctx, struct io_kiocb *req,
 	 * is potentially a read/write to block based storage.
 	 */
 	if (state->need_plug && io_op_defs[req->opcode].plug) {
-		blk_start_plug(&state->plug);
+		blk_start_plug_nr_ios(&state->plug, state->submit_nr);
 		state->plug_started = true;
 		state->need_plug = false;
 	}
@@ -7150,6 +7152,7 @@ static void io_submit_state_start(struct io_submit_state *state,
 {
 	state->plug_started = false;
 	state->need_plug = max_ios > 2;
+	state->submit_nr = max_ios;
 	/* set only head, no need to init link_last in advance */
 	state->link.head = NULL;
 }
Signature · 1 line
2.33.0