Re: smpnice loadbalancing with high priority tasks

[Peter Williams <pwil3058@bigpond.net.au>]

Siddha, Suresh B wrote:
> On Tue, Apr 04, 2006 at 11:22:23AM +1000, Peter Williams wrote:
> > OK.  I think this means some fiddling with avg_load may be necessary in 
> > some cases but this will be complex.  I'm not really happy about making 
> > this code more complex until some of the current unnecessary complexity 
> > is removed.  I.e. until a proper solution to the problem of triggering 
> > active_load_balance() is implemented.
>
> Here is Nicks view about active_load_balance()
>
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3950745131e23472fb5ace2ee4a2093e7590ec69

That's pre smpnice. :-)

> > > c) DP system: if the cpu-0 has two high priority and cpu-1 has one normal
> > > priority task, how can the current code detect this imbalance..
> > How would it not?
>
> imbalance will be always < busiest_load_per_task and
> max_load - this_load will be < 2 * busiest_load_per_task...
> and pwr_move will be <= pwr_now...

I had thought about substituting (busiest_load_per_task + 
this_load_per_task) for (busiest_load_per_task * 2) but couldn't 
convince myself that it was the right thing to do.  (The final update to 
this_load_per_task would need to be moved.)  The reason I couldn't 
convince myself is that I thought it might be too aggressive and cause 
excessive balancing.  Maybe something more sophisticated is needed to 
prevent that possibility.  It should be noted that the relative sizes of 
busiest_load_per_task and this_load_per_task my be useful in deciding 
what to do in these cases.  I'll put some thought into that.

BTW load balancing without smpnice would do just as badly here in that 
it wouldn't notice an imbalance either.

> > > d) 4-way MP system: if the cpu-0 has two high priority tasks, cpu-1 has
> > > one high priority and four normal priority and cpu-2,3 each has one
> > > high priority task.. how does the current code distribute the normal
> > > priority tasks among cpu-1,2,3... (in this case, max_load will always
> > > point to cpu-0 and will never distribute the noraml priority tasks...)
> > This should cause cpu-0 to lose one of its tasks creating a new state 
>
> how? in this case also...
>
> imbalance will be always < busiest_load_per_task and
> max_load - this_load will be < 2 * busiest_load_per_task...
> and pwr_move will be <= pwr_now...
>
>
> > Without smpnice, can you show how the default load balancing would 
> > result in the "nice" values being reliably enforced in your examples.
>
> I agree with the issue that we are trying to fix here.. but I feel
> it is incomplete.. With the current code in mainline, anyone can say the 
> behavior by going through the code.... with smpnice code, code is complex
> and really doesn't achieve what that patch really wants to fix..

It does in most cases and we could reduce the complexity if we had an 
alternative trigger for active_load_balance() :-)

> > The good news is that, in real life, high priority tasks generally only 
> > use very short bursts of CPU. :-)
>
> do we then really need smpnice complexity?

Most people who express unhappiness with SMP and nice are looking at the 
other end of the problem i.e. they nice 19 a process to make it run in 
the background but it gets a CPU to itself while a couple nice 0 tasks 
have to share the other CPU.  The high priority case has to be 
considered as well (e.g. one high priority task and one normal priority 
task running on a 2 CPU machine with a CPU each when another task wakes 
-- you'd like that to end up on the CPU of the normal priority task not 
the one with the high priority task, etc.) but its effects are more 
likely to be transitory and high priority tasks would not be expected to 
have a long term effect on balancing.

Peter
--
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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/