Disk seeks article [Re: New Optimization Section on d.g.o]

[Mark McLoughlin <markmc redhat com>]

Hi Robert,

On Mon, 2004-09-27 at 00:07, Robert Love wrote:
> On Mon, 2004-09-27 at 10:26 +1200, Callum wrote:
> 
> > Currently "Optimizing GNOME Software" contains a single article on using
> > Massif for memory profiling. I hope to be able to get a couple more
> > articles up myself, but further contributions (and criticism of the
> > existing article) will be very welcome.
> 
> Oh, here is an article!

	In articles like this, I think it'd be nice to have details to allow
people to diagnose/simulate the problem and quantify the improvements
from any changes. That's because you'll often need to make tradeoffs
based on cold, hard data.

	What I'd hate to see is people taking such an article literally and
running around reducing the number of seeks GNOME does while pointedly
ignoring the side effects the patches might introduce.

	 e.g. GConf has lots of little files spread across the disk. We have
code to consolidate all those little files into one big file or a small
number of big files. Code isn't the problem. What we need is some way of
making a decision based on real world measurements of the seek times
with lots of little files vs. the parsing time and memory usage of a big
file.

	When I wrote the GConf patch, I had a hard time figuring out how to get
useful data in order to make the tradeoff:

  http://mail.gnome.org/archives/gconf-list/2003-July/msg00001.html

	I guess there's a few things I'd love to be able to do:

  1) Simulate initial startup time by completely clearing the disk cache
     before taking measurements

  2) Simulate the files-scattered-across-the-disk problem

  3) Profile the disk accesses made by an application - disk seeks, 
     cache misses, read times etc. etc.

  4) Profile the disk accesses happening at login - i.e. with multiple 
     applications all doing lots of disk accesses, who are the ones
     doing all the reading and who are the ones getting hammered because
     they have to wait for their turn?

Thanks,
Mark.