Hi,
On 04/06/06 00:51, Alexander Kolbasov wrote:
Hello,
here is you chance to bite a piece of the scheduler code.
The purpose of the fix is to make idle thread less less aggressive in stealin
work from other CPUs when the work was only placed on the run-queue recently.
The diffs are available at
http://cr.grommit.com/~akolb/sticky/index.html
The changes look solid.
I have one question. It looks like disp_getwork will traverse the
other cpus (relative to the argument) in a deterministic order
for a given cpu and lgroup configuration (I may be wrong there -
it's not obvious!). So is there a chance that cpu A in the idle
loop might keep failing to find work to do if it keeps getting
"don't steal" back from disp_getbest for some cpu which keeps
turning up in the disp_getwork loop as having the highest
unbound pri of all. This may, I think, happen if some cpu
has say an FX class thread of high fixed priority that
keeps running and then blocking for a very short time.
Maybe a pathalogical worry!
I also wonder whether the pre-existing loop over cpus (in lpl order)
in disp_getwork on systems with many cpus is going to access
a large number of cpu_t and effectively flush the TLBs (as happened
in the mutex_vector_enter perf fix). I guess this is a less frequent
operation and the cpu is idle anyway.
Cheers
Gavin
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
