RE: call for more SD versus CFS comparisons (was: Re: [ck] Mainline plans)

["Tobias Gerschner" <tobias.gerschner@gmail.com>]

Hi,

> > I did run massive_intr.c for 60 secs with increasing nproc (
> > 10,20,30,40,50,60) waiting for effects.
> >
> > Below a small table of the results
> >
> > 2.6.21.1-cfs-v16
> >
> > nproc ,  usability result
> >
> > 10 , serious frame drops , Firefox  hardly recognizes clicked links,
> > but still usable
> > 20 - 30, usability loss ( somehow under cfs firefox never finished
> > user requests like displaying web pages or opening new pages , no
> > feedback anymore, sudden changes on the desktop )
>
> ouch! The expected load-testing result under CFS should be something
> like this:
>
>   http://bhhdoa.org.au/pipermail/ck/2007-June/007817.html
>
> could you send me the output of /proc/sched_debug? (while say a
> "massive_intr 20" is running?)
>
> Roughly what hardware do you have? (could you send me your lspci -v
> output and dmesg output?)
>
>      Ingo

Hi,


After some serious but fun testing on my machine over hours, Ingo got
CFS behave on par with SD. It was my understanding that the changes
were mainly adjusting tunables rather than changing code. But that is
not for me to explain.

> From my point of view it was impressive to see the determination INGO
had, to make sure he delivers the best he can :) . And I learned a lot
how to provide usable / readable test results.

So thumbs up for CFS and SD . ALL IMO: The current advantage of SD
over CFS is the lack of need of tuning for SD . So there is certainly
room for improvement for CFS.

Over the weekend I'll prepare some test cases and documentation for
them to test CFS and SD more specific so that a broader public can
provide the same sort of (comparable) data. The test we used only
covered 1 usage case. This is certainly not enough to measure the
performance of such a key component.

I am looking forward to the next version of CFS and I will certainly
test it toroughly.

kind regards to all responsiveness junkees

--
Tobias Gerschner
Member of Board of Yoper Linux Ltd. NZ

Knowing is not enough; we must apply. Willing is not enough; we must do.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/