On Monday 09 August 2004 22:40, you wrote:Rick showed me schedstats graphs of the two ... it seems to have lower
latency, does less rebalancing, fewer pull_tasks, etc, etc. Everything
looks better ... he'll send them out soon, I think (hint, hint).
Okay, they're done. Here's the URL of the graphs:
http://eaglet.rain.com/rick/linux/staircase/scase-vs-noscase.html
General summary: as Martin reported, we're seeing improvements in a number
of areas, at least with sdet. The graphs as listed there represent stats
from four separate sdet runs run sequentially with an increasing load.
(We're trying to see if we can get the information from each run
separately, rather than the aggregate -- one of the hazards of an automated
test harness :)
What's quite interesting is that there is a very noticeable surge in load_balance with staircase in the early stage of the test, but there appears to be -no- direct policy changes to load-balance at all in Con's patch (or at least I didn't notice it -please tell me if you did!). You can see it in busy load_balance, sched_balance_exec, and pull_task. The runslice and latency stats confirm this -no-staircase does not balance early on, and the tasks suffer, waiting on a cpu already loaded up. I do not have an explanation for this; perhaps it has something to do with eliminating expired queue.
I would be nice to have per cpu runqueue lengths logged to see how this plays out -do the cpus on staircase obtain a runqueue length close to nr_running()/nr_online_cpus sooner than no-staircase?
Also, one big change apparent to me, the elimination of TIMESLICE_GRANULARITY.
Do you have cswitch data? I would not be surprised if it's a lot higher on -no-staircase, and cache is thrashed a lot more. This may be something you can pull out of the -no-staircase kernel quite easily.
-Andrew Theurer