ureadahead improvements ( was: Readahead Maverick )

[Phillip Susi]

This conversation died earlier this year.  I decided to rebase my 
changes on natty and test again and I thought I would post the results 
on the mailing list and encourage testing this time.  If Scott can find 
time to review the changes, they are in 
lp:~psusi/ubuntu/natty/ureadahead/mine.  Anyone interested in testing 
can find the package in my PPA.

I ran a few boot time trials with a clean install of today's natty build 
on an lvm partition on my 1.5tb wd green drive.  The results were:

Initial baseline: 17.01 seconds
With my ureadahead: 15.33 seconds
After defrag: 15.82 seconds
Back to stock ureadahead: 16.25 seconds

I defragmented ( with e2defrag ) the drive giving packing priority to 
the files in the ureadahead list.  I am attaching before and after 
graphs of the blocks made with fragraph.py ( in the upstream ureadahead 
contrib directory ).  You can see that it looks better, and it did 
result in ureadahead finishing in 3 seconds instead of 5, but for some 
reason the overall boot took slightly longer.

On 07/30/2010 04:44 PM, Phillip Susi wrote:
> On 7/28/2010 10:15 AM, Scott James Remnant wrote:
>> Right, this is the kind of thing that only works when you have
>> explicitly laid the disk out in the right way, and is completely ruined
>> as soon as any part of the disk is changed (e.g. packages installed).
>>
>> I've avoided relying on directories always being in depth order on the
>> disk for the time being, because without a reprofile and defrag after
>> every boot, it drifts over time and the performance penalty can be
>> terrible.
>
> I had made similar modifications to do a two pass read getting the
> directories first and found that it caused a very slight slowdown
> without a defrag to place the directories before the normal files.  Once
> that was done though it made a good improvement.  The unmodified
> ureadahead spends about 1 full second in the open() loop with almost
> zero disk throughput as it fetches a single 4kb block from the disk at a
> time walking the directory tree.  Doing two passes over the disk is
> obviously less desirable than one, but the directory pass would have to
> take>  1 second to result in a net loss, which seems unlikely.
>
>> On an extents-based filesystem, reading the inodes will be entirely
>> separate to reading the contents.  So you'll incur twice as many passes
>> as on a non-extents-based filesystem.
>
> The currently live ureadahead already does this though; it preloads the
> inode table with calls to e2fslibs.  My version slightly modifies this
> to use readahead() to load the table without copying it to user space,
> rather than calling e2fslibs which ends up using read() into a user
> space buffer, and reads the next inode table beyond the one that
> actually has relevant inodes before stopping.
>
>> (ext3 converted to ext4 is *not* extents based for files that previously
>> existed - they must be rewritten)
>
> Or you can chattr +e.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: before.svg.bz2
Type: application/x-bzip
Size: 509317 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20101223/80d6d51c/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: after.svg.bz2
Type: application/x-bzip
Size: 507358 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20101223/80d6d51c/attachment-0003.bin>