geom <-> cam disk

[Ivan Voras]

On 26/07/2012 00:36, Andriy Gapon wrote:
> 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).

Is the queue drained in-order (i.e. after sorting)? Then it could help
as the device queues will be filled with requests whose offsets are
closer together (as opposed to totally random), which helps with bursts
(e.g. untarring the ports tree).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20120726/c3b03c1e/signature.pgp