FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Development

 
 
LinkBack Thread Tools
 
Old 03-12-2009, 03:31 PM
Scott James Remnant
 
Default sreadahead vs. readahead & foreground vs. background

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@ubuntu.com
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 

Thread Tools




All times are GMT. The time now is 05:19 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org