From owner-svn-src-stable@FreeBSD.ORG Wed Jun 5 16:25:39 2013 Return-Path: Delivered-To: svn-src-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D8F7582E for ; Wed, 5 Jun 2013 16:25:39 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm48-vm7.bullet.mail.ne1.yahoo.com (nm48-vm7.bullet.mail.ne1.yahoo.com [98.138.121.119]) by mx1.freebsd.org (Postfix) with ESMTP id A104511AE for ; Wed, 5 Jun 2013 16:25:39 +0000 (UTC) Received: from [98.138.90.56] by nm48.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2013 16:20:04 -0000 Received: from [98.138.84.41] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2013 16:20:04 -0000 Received: from [127.0.0.1] by smtp109.mail.ne1.yahoo.com with NNFMP; 05 Jun 2013 16:20:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370449204; bh=KIT0ZdNPozqdIjjsXRe0I5n4FKaKutkAYvjAKdllP/g=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:Mime-Version:Content-Type:From:X-Priority:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=iFc7IYdwXjSPha1Bll/y/YcngHILVOfELE85Splx+XagFsysSbLigSktguHQXO5yQ/KOgENyPomqiI6MUqUmnl35nsqnvSrFrS1BWfVLCM01ykNNyXRIv+W0mIPSLBxNSbJ/mcQG2le9C8YNh28q67KtZdErEshKE963Y/1Iaec= X-Yahoo-Newman-Id: 162850.40359.bm@smtp109.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: U6tdZ8kVM1lQslKauY7GRm9xsb7VrouRT1qQkSSyh_nsAga Q7IfqFx9eruPTzg5hjl6UGEcdUQ4z1.fb95t6AgaBpMabdQqHdEM0ldREZvx nWNDL5LDw.pK19zSzpe3sFMwZwI1GtVhBLUlO089P0gYEcUtK.V_iR7kTeoJ aaKL5AYKxXG9zTLeCjaZyYbPENyGLLSBMRyy98PCVE14n3VLBdMQm1Sfwh23 sLtS1f_jr2F6Zmuf1T7.09x69Cui4TgAPr00ECV2Di9fSf8DVbP01er.jVJm IAnaTHvOMNAt9CalpGht3cAjuzpG3_ft.c2N7QaWQ9Cdq3zPtUuhQbiyWHAM a73mjhDxGWDFXVYEB5P2HLtGa826U.si6pnSDiIWmskfP5iVQ.e7l0FFCN2W HWNXQhYcYWZy4d4gHbdVZpR_xpbQ7gn9GonhwRBaPkeSUyy6xDSR4iIpztDk tlorYaipXB7oAzOEzFwz4iRfHBDhhC1c1hRdYOupYIqX4Vq7PWgJTSa62hOO U X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from phobos.samsco.home (scott4long@168.103.85.57 with ) by smtp109.mail.ne1.yahoo.com with SMTP; 05 Jun 2013 09:20:04 -0700 PDT Subject: Re: svn commit: r251372 - in stable/9/sys/cam: ata scsi Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long X-Priority: 3 In-Reply-To: <491E54742FDD4C299688DE36717EA531@multiplay.co.uk> Date: Wed, 5 Jun 2013 10:20:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6F4A05CA-5C95-4862-9FBA-0352B7132214@yahoo.com> References: <201306041047.r54AljAX050733@svn.freebsd.org> <4A91EB3F-56FD-4E94-9981-0422032C9240@scsiguy.com> <491E54742FDD4C299688DE36717EA531@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1503) Cc: "Justin T. Gibbs" , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:25:39 -0000 On Jun 5, 2013, at 9:02 AM, Steven Hartland = wrote: >=20 >=20 > ----- Original Message ----- From: "Justin T. Gibbs" = >=20 >=20 > On Jun 4, 2013, at 3:47, Steven Hartland wrote: >=20 >> > Author: smh >> > Date: Tue Jun 4 10:47:44 2013 >> > New Revision: 251372 >> > URL: http://svnweb.freebsd.org/changeset/base/251372 >> > > Log: >> > Enhanced BIO_DELETE support for CAM SCSI to add ATA_TRIM support. >> > > Disable CAM BIO queue sorting for non-rotating media by default. >>=20 >> Using the elevator makes perfect sense even for random access devices = when >> operations can be merged. Even SSDs have fixed, per-command overheads = and >> merging writes may help prevent fragmentation. On drivers that = support >> unmapped I/O, merging should be fairly cheap. >>=20 >> It would be an interesting performance experiment. >=20 > In theory I'd agree but in practice this was not the case with bioq > becoming a noticable bottleneck for SSD based machines, hence this = change. >=20 > The sysctl's still allow this to be configured :) >=20 Completely agree. The bioq_disksort() only serves to burn CPU cycles = with the column lock held (thus burning even more CPU cycles elsewhere) = once the queue grows to any appreciable size. Merging of adjacent = segments happens (mostly) right now thanks to lock serialization in the = issuing path and g_down thread serialization. Furthermore, = bioq_disksort() has no concept of the cost of reads vs writes as they = pertain to SSDs. It's better to have the order be random and/or = somewhat separated thanks to operational serialization, than to try = extra hard to gets reads and writes close together. A much better I/O scheduler is needed. In our tests, bioq_disksort() is = worse than no i/o scheduler, so we've turned it off. We've tried = Luigi's scheduler, but it adds too much latency to our workload. I'm = working on a better scheme. Scott