sreadahead vs. readahead & foreground vs. background

[Scott James Remnant]

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
cache).

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
again.

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
longer!

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
-- 
Scott James Remnant
scott at ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: command-jaunty-20090311-2.png
Type: image/png
Size: 387280 bytes
Desc: 
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090312/818261b2/attachment-0008.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conquer-jaunty-20090311-1.png
Type: image/png
Size: 440254 bytes
Desc: 
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090312/818261b2/attachment-0009.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: command-jaunty-20090311-3.png
Type: image/png
Size: 371686 bytes
Desc: 
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090312/818261b2/attachment-0010.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: command-jaunty-20090311-4.png
Type: image/png
Size: 349307 bytes
Desc: 
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090312/818261b2/attachment-0011.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: command-jaunty-20090311-5.png
Type: image/png
Size: 346073 bytes
Desc: 
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090312/818261b2/attachment-0012.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conquer-jaunty-20090311-2.png
Type: image/png
Size: 495495 bytes
Desc: 
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090312/818261b2/attachment-0013.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conquer-jaunty-20090311-3.png
Type: image/png
Size: 547260 bytes
Desc: 
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090312/818261b2/attachment-0014.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conquer-jaunty-20090311-4.png
Type: image/png
Size: 516274 bytes
Desc: 
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090312/818261b2/attachment-0015.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090312/818261b2/attachment-0001.pgp