Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-R0

[Lee Revell]

On Fri, 2004-09-03 at 02:36, Ingo Molnar wrote:
> * Lee Revell <rlrevell@xxxxxxxxxxx> wrote:
> 
> > -Q and later use the current method, which is like the above except
> > the second hump is discarded, as it is a function of the scheduling
> > latency and the period size rather than just the scheduling latency:
> > 
> > 	http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-Q6
> > 
> > So, don't be fooled by the numbers, the newest version of the patch is
> > in fact the best.  I have been meaning to go back and measure the
> > current patches with the old code but it's pretty low priority...
> 
> vanilla kernel 2.6.8.1 would be quite interesting to get a few charts of
> - especially if your measurement methodology has changed.

OK, I will give this a shot.  Now that the VP patches are stabilizing I
will be doing more profiling.  I also want to try the -mm kernel, this
has some interesting differences from the stock kernel.  For example I
measured about a 10% improvement with the old method, which implies a
big performance gain.

>  There's not
> much sense in re-testing older VP patches.
> 

Yup, my thoughts exactly, this would just tell us what we already know,
that the latency gets better with each version.

> also, has the userspace workload you are using stayed constant during
> all these tests?
> 

I am mostly just using normal desktop hacker workloads, web browsing,
email, builds.  Lately I am using the box as a Samba server.  At first,
I was stressing the system using every disk benchmark I could think of,
but it never seemed to affect the worst case and did not even change the
shape of the distribution much, so I don't bother.  For all practical
purposes, it's impossible to change the shape of these graphs much by
stressing the system.

I am able to induce large latencies by using up all available swap with
make -j12 on a KDE program, and by pingflooding the broadcast address,
but these are pathological enough that I have not worried about them.

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/