Re: [ RFC, PATCH 1/5 ] CPU controller - base changes
From: Srivatsa Vaddagiri
Date: Fri Aug 04 2006 - 10:45:39 EST
On Fri, Aug 04, 2006 at 06:34:00PM +0400, Kirill Korotaev wrote:
> AFAICS, you wanted to go the way we used in OpenVZ - 2-level scheduling.
> However, you don't do any process balancing between runqueues taking into
> other groups.
> In many cases you will simply endup with tasks collected on the same
> CPU and poor performance. I'm not talking about fairness (proportinal CPU
> I don't think it is possible to make any estimations for QoS of such a
Yes, the patch (as mentioned earlier) does not address SMP correctness
_yet_. That will need to be addressed definitely for an acceptable
controller. My thought was we could try the smpnice approach (which
attempts to deal with the same problem albeit for niced tasks) and
see how far we can go. I am planning to work on it next.
> What do you think about a full runqueue virtualization, so that
> first level CPU scheduler could select task-group on any basis and then
> arbitrary runqueue was selected for running?
That may solve the load balance problem nicely. But isnt there some cost
to be paid for it (like lock contention on the virtual runqueues)?
> P.S. BTW, this patch doesn't allow hierarchy in CPU controler.
Do we want heriarchy?
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/