[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