That was me/us. Most of the reason for making 'global scheduling'
decisions was an attempt to maintain the same behavior as the existing
scheduler. We are trying to see how well we can make this scheduler
scale, while maintaining this global behavior. Thought is that if
there was ever any hope of someone adopting this scheduler, they would
be more likely to do so if it attempted to maintain existing behavior.
> I think that this concept could be relaxed introducing less chains between each
> CPU scheduler.
> A cheap load balancer should run, "time to time"(tm), to move tasks when a
> certain level of unbalancing has been reached.
> This will give each scheduler more independence and will make it more scalable,
> IMVHO.
Take a look at the 'CPU pooling & Load balancing' extensions to our
scheduler(lse.sourceforge.net/scheduling). It allows you to divide
the system into CPU pools keep scheduling decisions limited to
these pools. Periodicly, load balancing will be performed among
the pools. This has shown some promise on NUMA architectures (as
one would expect). You could define pool sizes to be 1 CPU and
get the scheduling behavior you desire on SMP.
But, none of this has to do with CPU affinity issues with the
current scheduler.
-- Mike Kravetz mkravetz@sequent.com IBM Linux Technology Center - 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/