lkml.org 
[lkml]   [2004]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2.6.8-rc2-mm2 performance improvements (scheduler?)
Date
From
    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.

Possibly. The other factor thrown in here is that this was on an SMT
machine, so it's possible that the balancing is no different but we are
seeing tasks initially assigned more poorly. Or, perhaps we're drawing
too much from one data point.

It 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?

The only difficulty there is do we know how long it normally takes for
this to balance out? We're taking samples every five seconds; might this
not work itself out between one snapshot and the next? Shrug. It would
be easy enough to add another field to report nr_running at the moment
the statistics snapshot was taken, but on anything but compute-intensive
benchmarks I'm afraid we might miss all the interesting data.

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.

Yes, sar data was collected every five seconds so I do have context switch
data. The bad news is that it was collected for each of 10 runs times
four different loads, and I don't have any handy dandy scripts to pretty
it up :) (Pause.) A quick exercise with a calculator, though, suggests
you are right. cswitches were 10%-20% higher on the no staircase runs.

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

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.089 / U:1.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site