Date: Thu, 26 Jul 2012 01:36:20 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-scsi@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: geom <-> cam disk Message-ID: <501074E4.4040805@FreeBSD.org> In-Reply-To: <50106E5F.4030402@FreeBSD.org> References: <501056C4.3080806@FreeBSD.org> <50106E5F.4030402@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 26/07/2012 01:08 Alexander Motin said the following: > Different controllers have different command queueing limitations. If you are > testing with ahci(4) driver and modern disks, then their 32 command slots per > port can be enough for many workloads to enqueue all commands to the hardware > and leave queue empty as you've described. But if you take harder workload, or > controller/ device without command queueing support, extra requests will be > accumulated on that bioq and sorted there. Alexander, thank you for the reply. Indeed, using 64 parallel dd processes with bs=512 I was able to 'kick in' the disksort logic. But I am not sure if the disksort algorithm makes much difference in this case given the number of commands that a disk firmware can internally re-order. (Not mentioning that potentially disksort could starve some I/O bound processes in favor of others -- but that's a totally different topic). But then, of course, for the less capable hardware the disksort could still be a significant factor. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?501074E4.4040805>