Re: [PATCH] sched: smpnice work around for active_load_balance()

[Peter Williams]

Peter Williams wrote:
> Siddha, Suresh B wrote:
> > On Tue, Mar 28, 2006 at 05:00:50PM +1100, Peter Williams wrote:
[bits deleted]
> > Even with no HT and MC, this patch has still has issues in the presence
> > of different priority tasks... consider a simple DP system and run two
> > instances of high priority tasks(simple infinite loop) and two normal 
> > priority
> > tasks. With "top" I observed that these normal priority tasks keep on 
> > jumping
> > from one processor to another... Ideally with smpnice, we would assume 
> > that each processor should have two tasks (one high priority and 
> > another one with normal priority) ..
>
> Yes, but you are failing to take into account the effect of the other 
> tasks on your system (e.g. top) that run from time to time.  If their 
> burst of CPU use happens to coincide with some load balancing activity 
> they will cause an imbalance to be detected (that is different to that 
> which only considers your test tasks) and this will result in some tasks 
> being moved.  Beware the Heisenberg Uncertainty Principle :-).

Notwithstanding the HUP, I've investigated this and have found that 
there is more instability than expected and that it is due to a silly 
bit of code (by me) at the end of find_busiest_queue() marked by the 
comment:

/* or if there's a reasonable chance that *imbalance is big
 * enough to cause a move
 */

that makes load balancing more aggressive.  The functionality it 
implemented should have been abandoned when the code was updated to use 
average run queue loads instead of SCHED_LOAD_SCALE in the code that 
handled small imbalances but wasn't.  I'll send Andrew a patch that 
removes the offending code shortly.

Peter
--
Peter Williams                                   pwil3058@xxxxxxxxxxxxxx

"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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/