Re: CFS: some bad numbers with Java/database threading [FIXED]

[Ingo Molnar]

* Chuck Ebbert <cebbert@xxxxxxxxxx> wrote:

> On 09/14/2007 11:32 AM, Ingo Molnar wrote:
> > * Antoine Martin <antoine@xxxxxxxxxxxxx> wrote:
> > 
> >>>> have an impact) Keep CONFIG_SCHED_DEBUG=y to be able to twiddle the
> >>>> sysctl.
> >> It looks good now! Updated results here:
> >> http://devloop.org.uk/documentation/database-performance/Linux-Kernels/Kernels-ManyThreads-CombinedTests5-10msYield-noload.png
> >> http://devloop.org.uk/documentation/database-performance/Linux-Kernels/Kernels-ManyThreads-CombinedTests5-10msYield.png
> >> Compared with more kernels here - a bit more cluttered:
> >> http://devloop.org.uk/documentation/database-performance/Linux-Kernels/Kernels-ManyThreads-CombinedTests4-10msYield-noload.png
> >>
> >> Thanks Ingo!
> >> Does this mean that I'll have to keep doing:
> >> echo 1 > /proc/sys/kernel/sched_yield_bug_workaround
> >> Or are you planning on finding a more elegant solution?
> > 
> > just to make sure - can you get it to work fast with the 
> > -rc6+yield-patch solution too? (i.e. not CFS-devel) We need a (tested) 
> > solution for 2.6.23 and the CFS-devel patches are not for 2.6.23. I've 
> > attached below the latest version of the -rc6 yield patch - the switch 
> > is not dependent on SCHED_DEBUG anymore but always available.
> > 
> 
> Is this going to be merged? And will you be making the default == 1 or 
> just leaving it at 0, which forces people who want the older behavior 
> to modify the default?

not at the moment - Antoine suggested that the workload is probably fine 
and the patch against -rc6 would have no clear effect anyway so we have 
nothing to merge right now. (Note that there's no "older behavior" 
possible, unless we want to emulate all of the O(1) scheduler's 
behavior.) But ... we could still merge something like that patch, but a 
clearer testcase is needed. The JVM's i have access to work fine.

	Ingo
-
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/