----- Original Message -----
From: "Andriy Gapon" <a...@freebsd.org>
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.
The sort is actually important for delete requests too as this can allow
the delete processing code to operate more effectively which can result in
significant performance increases if this then allows request combining.
For example Alexander is currently reviewing some changes I've written to the
delete processing which include an optimisation that increases SSD delete
performance from ~630MB/s to 1.3GB/s on 3rd gen sandforce controllers.
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
