Now that sreadahead is available in the archive, I keep getting asked
what the difference between the two is, and which you should use.
Here's two bootcharts of the ideal cases:
The attached file command-jaunty-20090311-2.png shows a boot with an
HP Mini 1000 with an SSD disk.
Since this disk is SSD, seek time is just not an issue. Thus the
sreadahead cache is ordered based on access time, and can be run in the
background alongside other parts of the boot.
This is because is sreadahead gets to the block first, we win because
we've read it ahead of time. If the program that wanted it gets to it
first, it'll be a no-op when sreadahead gets to it later (already in
So it's always an improvement and never "worse".
The attached file conquer-jaunty-20090311-1.png shows a boot with a
HP Mini 1000 with an ordinary non-SSD hard drive.
Since this disk is a hard drive, seek time is now a major issue. Thus
the readahead list is ordered based on physical on-disk location. And
we cannot run it in the background.
This is because we need to minimise seek as much as possible. If we ran
it in the background, we'd be competing for disk access with other
processes. We'd be seeking back and forth all over the disk, and thus
have a net loss.
Whereas sreadahead was never "worse" (except for a minor overhead),
readahead can send the boot time through the roof.
To illustrate the differences there are further charts attached:
command-jaunty-20090311-3.png is from the SSD model, but with sreadahead
moved into the foreground. Waiting for it is a penalty, we're doing
disk stuff when there's other things to be getting on with.
command-jaunty-20090311-4.png is from the SSD model, but using readahead
instead of sreadahead. There's a slight penalty from foregrounding
command-jaunty-20090311-5.png is from the SSD model, but using readahead
instead of sreadahead AND putting readahead into the background instead
of the foreground. Here we're reasonably comparable to sreadahead,
since not much is disk-critical that early.
conquer-jaunty-20090311-2.png is from the hard drive model, but with
readahead moved into the background. Notice how the readahead process
is now much longer, there's much more I/O throughout the boot - which is
a few seconds longer.
conquer-jaunty-20090311-3.png is from the hard drive model, but using
sreadahead instead of readahead. Now we're just randomly seeking all
over the disk, the phase lasts almost the entire boot which is much much
conquer-jaunty-20090311-4.png is from the hard drive model, but using
sreadahead instead of readahead AND putting sreadahead into the
foreground instead of the background. No good
that seeking all over
the disk isn't even good when it's all we're doing.
Aside from straight performance differences, sreadahead has a much
better ftrace-based profiler which has very little overhead meaning we
can regenerate the boot charts on a regular basis (e.g. monthly) and by
default includes the desktop environment.
Ideally we would port the hard-disk-friendly "order by block and run in
foreground" mode to sreadahead.
May I have the next slide, please...
Scott James Remnant
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel