Subject: Re: UBC performance patch
To: None <hubert.feyrer@informatik.fh-regensburg.de, lennart@mail.augustsson.net>
From: None <eeh@netbsd.org>
List: tech-kern
Date: 01/24/2001 15:45:34
	On Wed, 24 Jan 2001, Lennart Augustsson wrote:
	> I'm not sure how to make benchmarks for all of these things.  How do
	> you test interactive responsiveness in a benchmark (without having
	> someone clicking and clocking)?  I'm sure it's possible, but it will
	> require some thought.

	Maybe see how much CPU time was spent during (e.g.) extracting mozilla
	source, and see how much was left to the X server etc.?

The interactive response proplem is not due to lack of CPU time,
rather it is due to memory shortages and pageoutes.  I expect
you will find plenty of idle time during that situation.  What's
happening is that tue buffer cache's `working set' is forcing 
everything else out of memory and causing the machine to thrash.
I'm not certain this is objectively measurable.

You could keep track of pageouts during heavy I/O operations, but
this is not guaranteed to give good results.  Pages of the X server
and important applications are being evicted, and those pages are
needed to handle input and screen refresh.  However, since user
I/O is sporadic, those pages are good candidates for pageout.

What you could do to simulate this situation is have an application
that sleeps for a random amount (1-60 seconds) then touches a large
number of text and data pages (a couple of megabytes each), and time
how long it takes to complete touching the pages.  Comparing the time
required on an idle system and on a busy system will give you the 
difference in responsiveness.  It would be best if the accesses were
in a fixed pattern so you get consistent performance numbers.

Eduardo