Date: Thu, 03 Sep 2009 19:08:02 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Scott Long <scottl@samsco.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r196777 - head/sys/dev/ahci Message-ID: <4A9FE9E2.1060205@FreeBSD.org> In-Reply-To: <20090903095224.N20031@pooker.samsco.org> References: <200909031237.n83CbIgk032551@svn.freebsd.org> <1872D962-9297-4C45-9F73-4BB823C49D74@samsco.org> <4A9FD8B4.2080605@FreeBSD.org> <20090903095224.N20031@pooker.samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote: > On Thu, 3 Sep 2009, Alexander Motin wrote: >> Scott Long wrote: >>> In this case, set maxio to 64k, not 127.5k. You'll typically get >>> much better i/o performance out of two 64k transfers >>> than you will out of one 127.k transfer and one 512 bytes transfer, >>> which is what the block layer will give you if >>> you try to send 128k. >> >> Couldn't it be somehow handled on that level? > > It's a limitation of the paticular hardware, not the OS. Plain disks > will behave like this, but RAID controllers might now. But if you want > to add this feature to the upper layers, be my guest. Huh. May be sometimes later. >> Limiting maxio from 127.5K to 64K is also a penalty for requests with >> length in that range. > > Most I/O that goes to a disk comes from one of the VM pagers, and is > thus page aligned and multi-of-page sized. Breaking one of these > requests up into sub-page sized requests costs a whole lot more than > what you are assuming. We analyzed exactly this situation a few years > ago at Yahoo and came to this conclusion. Sure, 127.5K is ugly, but what's about 96K or 112K? Is there benefits having it strictly in power of 2? -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A9FE9E2.1060205>