lkml.org 
[lkml]   [1998]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Logging disk accesses.
From
Date
R.E.Wolff@BitWizard.nl (Rogier Wolff) writes:

> Etienne Lorrain wrote:
> > Is there someone who had enough time to try "benchmarking" the
> > different filesystems supported - and say which one is better
> > for performance, which one is better for responsiveness, which
> > one is better for safety ? Probably the latter is ext2, at least
> > I have successfully tested its crash recovery some times !
>
> As an example of where this "logging" could come in handy:
>
> My "netscape" starts up taking about 12 seconds before I see the screen.
> This is about 10 seconds of disk IO and 2 seconds of CPU.
>
> I now have a script that does:
>
> dd if=netscape.bin of=/dev/null bs=1024k
> netscape.bin $*
>
> This linearly reads netscape into memory, and costs a little over a
> second. Starting up netscape now only takes 5 seconds total... Thus
> the "demand paging" is not efficient in this case: the seeks cost much
> more than is gained by not reading part of the binary.
>
> The ideal situation would be that those parts of the binary that get
> loaded at startup would be linearly on the disk, those parts that
> don't get used at startup, just behind that:
>
> now: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
> referenced at startup 1 - - 4 - 2 - 5 - - - 3 6 - -
>
> fancy defrag: 1 6 12 4 8 13 2 3 5 7 9 10 11 14 15
> referenced at startup 1 2 3 4 5 6 - - - - - - - - -
>
> The "block accessed logger" would come in very handy to show you which
> blocks do get referenced while starting up a program.
>
> By the way, has anybody tried it yet?

Intel did something like this for windows95.

Another idea that might work with less disruption than moving blocks on
the disk would be a 'working set map'. That's a bitmap associated with the
binary that has bits set for all blocks that are needed during startup.
This bitmap could be feed to the existing kernel-readahead mechanisms to
read the binary as efficiently as possible [I know that mmap-like accesses
like demand paging don't do readahead currently, but it is probably not too
hard to add].

This bitmap would work as a hint to the readahead predictor. If there is a
non predicted IO operation it would no throw away this readahead information
immediately, but only after a (configurable) number of misses occured.

Generating this bitmap is easy using a profiler. For ELF it could be stored
in a special section of the binary.

-A.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:1.603 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site