Date: Wed, 5 Jun 2013 10:20:02 -0600 From: Scott Long <scott4long@yahoo.com> To: Steven Hartland <killing@multiplay.co.uk> Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-9@freebsd.org Subject: Re: svn commit: r251372 - in stable/9/sys/cam: ata scsi Message-ID: <6F4A05CA-5C95-4862-9FBA-0352B7132214@yahoo.com> In-Reply-To: <491E54742FDD4C299688DE36717EA531@multiplay.co.uk> References: <201306041047.r54AljAX050733@svn.freebsd.org> <4A91EB3F-56FD-4E94-9981-0422032C9240@scsiguy.com> <491E54742FDD4C299688DE36717EA531@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 5, 2013, at 9:02 AM, Steven Hartland <killing@multiplay.co.uk> = wrote: >=20 >=20 > ----- Original Message ----- From: "Justin T. Gibbs" = <gibbs@scsiguy.com> >=20 >=20 > On Jun 4, 2013, at 3:47, Steven Hartland <smh@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6F4A05CA-5C95-4862-9FBA-0352B7132214>