Michael Gerdau wrote:
That's because the whole premise of your benchmark relies on a workload that
yield()s itself to the eyeballs on most graphic card combinations when using
glxgears. Your test remains a test of sched_yield in the presence of your
workloads rather than anything else. If people like ck2 it's because in the
real world with real workloads it is better, rather than on a yield() based
benchmark. Repeatedly the reports are that 3d apps and games in normal usage
under -ck are better than mainline and cfs.
While I can't comment on the technical/implementational details of
Con's claim I definitely have to agree from a users POV.
Any of the sd/ck/cfs schedulers are an improvement on the current
mainline, and hopefully they will continue to cross pollinate and
evolve. Perhaps by 2.6.23 a clear "best" will emerge, or Linus will
change his mind and make sd and cfs be compile options at build time.
All my recent CPU intensive benchmarks show that both ck/sd and cfs
are very decent scheduler and IMO superior to mainline for all _my_
usecases. In particular playing supertux while otherwise fully utilizing
both CPUs on a dualcore works without any glitch and better than
on mainline for both sd and cfs.
I did some kernel compile timing numbers as part of my work with
ctxbench, and there is little to choose between the schedulers under
load, although the special case for sched_yield makes some loads perform
better with cfs. With large memory and fast disk, a kernel make becomes
a CPU benchmark, there's virtually no iowait not filled with another
process.
For me the huge difference you have for sd to the others increases the
likelyhood the glxgears benchmark does not measure scheduling of graphic
but something else.
The glitch1 script generates a number of CPU bound processes updating
the screen independently, which stresses both graphics performance and
scheduler fairness. And once again I note that it's a *characterization*
rather than a benchmark. The ability of the scheduler to deliver the
same resources to multiple identical processes, and to keep another CPU
bound process (glxgears) getting the processor at regular intervals is
more revealing than the frames per second or loops run.
I would expect sd to be better at this, since it uses a deadline
concept, but in practice the gears pause, and then move rapidly or
appear to jump. My reading on this is that the process starves for some
ms, then gets a lot of CPU because it is "owed" more. I think I see this
in games, but not being a game player I can't tell from experience if
it's artifact or the games suck. That's what my test rig, based on a 15
year old boy and several cans of high caffeine soda, is used for. ;-)
Anyway, I'm still in the process of collecting data or more precisely
until recently constantly refined what data to collect and how. I plan
to provide new benchmark results on CPU intensive tasks in a couple of
days.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
