If we go to the trouble of supporting scheduling groups, then it would
seem that one could define a 'global RT' group for any required global
semantics. The initial development costs (scheduling groups) may be
high, but you would get global RT semantics for free. I also believe
that we may be able to keep the overhead out of scheduling decisions for
tasks not in the groups. My only concern would be with groups that
span multiple CPUs (such as the global one). If the scheduler continues
to use a single lock (which I don't advocate), this is not much of an
issue. However, things can get quite complicated with multiple (per-CPU)
locks and the possibly required per-group synchronization items.
-- Mike - 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/