Re: BFS vs. mainline scheduler benchmarks and measurements

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > So ... to get to the numbers - i've tested both BFS and the tip of 
> > the latest upstream scheduler tree on a testbox of mine. I 
> > intentionally didnt test BFS on any really large box - because you 
> > described its upper limit like this in the announcement:
> 
> I ran a simple test as well, since I was curious to see how it performed
> wrt interactiveness. One of my pet peeves with the current scheduler is
> that I have to nice compile jobs, or my X experience is just awful while
> the compile is running.
> 
> Now, this test case is something that attempts to see what
> interactiveness would be like. It'll run a given command line while at
> the same time logging delays. The delays are measured as follows:
> 
> - The app creates a pipe, and forks a child that blocks on reading from
>   that pipe.
> - The app sleeps for a random period of time, anywhere between 100ms
>   and 2s. When it wakes up, it gets the current time and writes that to
>   the pipe.
> - The child then gets woken, checks the time on its own, and logs the
>   difference between the two.
> 
> The idea here being that the delay between writing to the pipe and the
> child reading the data and comparing should (in some way) be indicative
> of how responsive the system would seem to a user.
> 
> The test app was quickly hacked up, so don't put too much into it. The
> test run is a simple kernel compile, using -jX where X is the number of
> threads in the system. The files are cache hot, so little IO is done.
> The -x2 run is using the double number of processes as we have threads,
> eg -j128 on a 64 thread box.

Could you post the source? Someone else might get us
numbers... preferably on dualcore box or something...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html