Ingo Molnar wrote: > * Gregory Haskins wrote: > > >>>> Speaking of this: Another patch I submitted to you Ingo (had to do >>>> with updating the load_weight inside task_setprio) seems to also >>>> have this phenomenon: e.g. its technically correct but further >>>> testing has revealed negative repercussions elsewhere. So please >>>> ignore that patch (or revert if you already pulled in, but I don't >>>> think you have). Ill try to look into this issue as well. >>>> >>> ok, under which thread/subject is that? Not queued in tip/sched/* >>> yet, correct? >>> >>> >> Here is the original thread: >> >> http://lkml.org/lkml/2008/7/3/416 >> >> I do not believe you have queued it anywhere (public anyway) yet. >> >> Note I have already invalidated 1/2, and now I am retracting 2/2 as >> well. (1/2 is actually a bogus patch, 2/2 is "technically correct" >> but causes ripples in the load balancer that need to be sorted out >> first. >> > > ok, thanks. I'm curious, what are those ripple effects? Stability or > performance? > Performance. I found it while working on my pi series (which fyi I should have a v2 refresh for soon, probably today...i am hoping to get some review feedback from you on that as well, time permitting of course ;). Basically the behavior I was observing was that kernel builds via distcc would cluster all the cc1 jobs on a single core. At first I thought my pi-series was screwed up, but then I realized I had applied the patch referenced above earlier in my development tree, and removing it allowed pi to work fine. I found the problem with in once boot cycle with ftrace (thanks Steve!). Basically newidle balancing was always returning "no imbalance" even though I had 32 cc1 threads on 1 core, and 3 idle cores. Clearly not correct! So I think that by adjusting the load up, we throw off the hysteresis built into the load averages and cause the system to incorrectly think it's balanced. TBD. -Greg > Ingo >