[Ksummit-2008-discuss] Suggested topic: possible

Arjan van de Ven arjan at linux.intel.com
Wed Aug 6 13:35:22 PDT 2008


Andrew Morton wrote:
> Yes.  We've spent huge amounts of effort minimising seeks and
> maximising request sizes (and we still don't do it very well).
> 
> I assume that the returns from those optimisations is much smaller with
> SSD.

yeah pretty much zero

> 
> I assume that the return from request-size-maximisation on SSD is
> better than the return on seek-avoidance.

actually, this is a two-sided sword; SSDs are so fast that you're bandwidth bound basically.
We tend to only return to userland when the entire IO is done (for reads), even the read-aheaded
part. With being bandwidth-limited, this now turns into real extra, synchronous time. So it might
well be better to submit 2 IO's, one with the data you need and one with the data you might need later,
so that the first one can complete the nanosecond all the required bytes are in.


> I assume that we can beneficially throw away (ie: bypass) a large part
> of the filesystem and block layer seek-minimisation and
> request-size-maximisation code when the backing device is SSD.

yes.. as you can read on the linux-scsi list, matthew has been working on this already.

> 
> I assume that you guys know a lot more than me about my assumptions ;)
> I would be interested in hearing your opinions on all the above.  How
> many person-years worth of code did we just ditch?

A lot ;-)
> 
> Approximate numbers would be interesting.  On a spinning disk, the
> difference between ten-randomly-splattered-4k-writes and one-40k-write
> is about an order of magnitude.  How much of a benefit is it on SSD,
> present and future?

it'll be 1:1 or close to...
there is still some gain in grouping.. but it's a TON less.
Especially with hw features like interrupt mitigation as SATA controllers are growing.


More information about the Ksummit-2008-discuss mailing list