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.

MFC after:	2 weeks
Sponsored by:	iXsystems, Inc.
This commit is contained in:
Alexander Motin 2020-10-26 04:04:06 +00:00
parent d20d655018
commit 3c0177b887
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=367052

View File

@ -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 *bp)
head->insert_point = NULL;
TAILQ_REMOVE(&head->queue, bp, bio_queue);
if (TAILQ_EMPTY(&head->queue))
head->batched = 0;
head->total--;
}