Can we make readahead more robust to package updates?

[Karel Zak]

On Tue, Nov 14, 2006 at 08:15:26AM +0100, Arjan van de Ven wrote:
> On Mon, 2006-11-13 at 22:23 -0500, Bill Nottingham wrote:
> > Arjan van de Ven (arjan at fenrus.demon.nl) said: 
> > > I really like this idea; it's a simple "cat" and it can be done at a
> > > time where latency doesn't matter... (even in cron.daily)
> > > 
> > > Oh... this opens more options. This also allows the "sort by
> > > blocknumber" to be done at this point and taken out of the critical
> > > latency part......
> > > 
> > > great idea!
> > 
> > Of course, that then makes shutdown take twice as long.

 Definitely no. We don't talk about full readahead. 
 
 I've implemented the idea and it seems that we can use it during
 regular shutdown. 
 
 It's very fast, because almost all files from readahead lists are
 already in the cache (and don't forget we don't call readahead(2) and
 read full files. We need open(), stat() and read first block for each
 file only. This is 10x faster than full readahead which we know from
 system start up).
 
> if you do it at shutdown, which is again a latency path :)
> cron.daily/weekly is less so ;)

 Well, some numbers:

 ./readahead --timing --verbose \
        --output /etc/readahead.d/early.sorted \
        --sort /etc/readahead.d/default.early

 List: /etc/readahead.d/default.early
 Time (read lists): 0 ms
 Create list with 850 files
 Time (read blocks): 103 ms                 <---------
 Read blocks for 726/850 files (65778 KB)

 List: /etc/readahead.d/default.later
 Time (read lists): 2 ms
 Create list with 3757 files
 Time (read blocks): 281 ms                 <----------
 Read blocks for 3056/3757 files (110159 KB)


 The worst numbers which I've ever seen was 2500ms (sum from both lists)
 and it was on an laptop with a lazy HDD.

 Also, the idea that we can run it as parallel process is useful.

 If you want to play with new readahead code, see:

 http://people.redhat.com/kzak/readahead/readahead-11276006.tar.gz

    Karel

-- 
 Karel Zak  <kzak at redhat.com>