lkml.org 
[lkml]   [1998]   [Jun]   [3]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Logging disk accesses.
FromAndi Kleen <>
Date03 Jun 1998 12:28:24 +0200
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 12:42    [from the cache]
©2003-2008