From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 23:47:11 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C1AF106566B; Wed, 25 Jul 2012 23:47:11 +0000 (UTC) (envelope-from prvs=1553f1cdfa=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id F0C9C8FC14; Wed, 25 Jul 2012 23:47:09 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Thu, 26 Jul 2012 00:46:04 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50020941215.msg; Thu, 26 Jul 2012 00:46:04 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1553f1cdfa=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <91A8B33A32B546BB82F0A1CFF4D1F4BD@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" , "Alexander Motin" References: <501056C4.3080806@FreeBSD.org> <50106E5F.4030402@FreeBSD.org> <501074E4.4040805@FreeBSD.org> Date: Thu, 26 Jul 2012 00:46:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-scsi@FreeBSD.org, freebsd-geom@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 23:47:11 -0000 ----- Original Message ----- From: "Andriy Gapon" > 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.