svn commit: r367505 - stable/12/sys/kern

[Alexander Motin]

Author: mav
Date: Mon Nov  9 01:13:28 2020
New Revision: 367505
URL: https://svnweb.freebsd.org/changeset/base/367505

Log:
  MFC r367052: Enable bioq 'car limit' added at r335066 at 128 bios.
  
  Without the 'car limit' enabled (before this), running sequential ZFS scrub
  on HDD without command queuing support, I've measured latency on concurrent
  random reads reaching 4 seconds (surprised that not more).  Enabling this
  reduced the latency to 65 milliseconds, while scrub still doing ~180MB/s.
  
  For disks with command queuing this does not make much difference (if any),
  since most time all the requests are queued down to the disk or HBA, leaving
  nothing in the queue to sort.  And even if something does not fit, staying on
  the queue, it is likely not for long.  To not limit sorting in such bursty
  scenarios I've added batched counter zeroing when the queue is getting empty.
  
  The internal scheduler of the SAS HDD I was testing seems to be even more
  loyal to random I/O, reducing the scrub speed to ~120MB/s.  So in case
  somebody worried this is limit is too strict -- it actually looks relaxed.

Modified:
  stable/12/sys/kern/subr_disk.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/kern/subr_disk.c
==============================================================================
--- stable/12/sys/kern/subr_disk.c	Mon Nov  9 00:39:48 2020	(r367504)
+++ stable/12/sys/kern/subr_disk.c	Mon Nov  9 01:13:28 2020	(r367505)
@@ -26,7 +26,7 @@ __FBSDID("$FreeBSD$");
 #include <sys/sysctl.h>
 #include <geom/geom_disk.h>
 
-static int bioq_batchsize = 0;
+static int bioq_batchsize = 128;
 SYSCTL_INT(_debug, OID_AUTO, bioq_batchsize, CTLFLAG_RW,
     &bioq_batchsize, 0, "BIOQ batch size");
 
@@ -172,6 +172,8 @@ bioq_remove(struct bio_queue_head *head, struct bio *b
 		head->insert_point = NULL;
 
 	TAILQ_REMOVE(&head->queue, bp, bio_queue);
+	if (TAILQ_EMPTY(&head->queue))
+		head->batched = 0;
 	head->total--;
 }