Ingo Molnar wrote:* Gregory Haskins <ghaskins@xxxxxxxxxx> wrote:
Here is the original thread: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?
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
Attachment:
signature.asc
Description: OpenPGP digital signature