Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Jul 2012 00:46:11 +0100
From:      "Steven Hartland" <killing@multiplay.co.uk>
To:        "Andriy Gapon" <avg@FreeBSD.org>, "Alexander Motin" <mav@FreeBSD.org>
Cc:        freebsd-scsi@FreeBSD.org, freebsd-geom@FreeBSD.org, freebsd-hackers@FreeBSD.org
Subject:   Re: geom <-> cam disk
Message-ID:  <91A8B33A32B546BB82F0A1CFF4D1F4BD@multiplay.co.uk>
References:  <501056C4.3080806@FreeBSD.org> <50106E5F.4030402@FreeBSD.org> <501074E4.4040805@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- 
From: "Andriy Gapon" <avg@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 postmaster@multiplay.co.uk.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91A8B33A32B546BB82F0A1CFF4D1F4BD>