Re: [RFC] scheduler: improve SMP fairness in CFS

[Chris Snook]

Bill Huey (hui) wrote:
> On Tue, Jul 24, 2007 at 04:39:47PM -0400, Chris Snook wrote:
> > Chris Friesen wrote:
> > > We currently use CKRM on an SMP machine, but the only way we can get away 
> > > with it is because our main app is affined to one cpu and just about 
> > > everything else is affined to the other.
> > If you're not explicitly allocating resources, you're just low-latency, not 
> > truly realtime.  Realtime requires guaranteed resources, so messing with 
> > affinities is a necessary evil.
>
> You've mentioned this twice in this thread. If you're going to talk about this
> you should characterize this more specifically because resource allocation is
> a rather incomplete area in the Linux.

Well, you need enough CPU time to meet your deadlines.  You need pre-allocated 
memory, or to be able to guarantee that you can allocate memory fast enough to 
meet your deadlines.  This principle extends to any other shared resource, such 
as disk or network.  I'm being vague because it's open-ended.  If a medical 
device fails to meet realtime guarantees because the battery fails, the 
patient's family isn't going to care how correct the software is.  Realtime 
engineering is hard.

> Rebalancing is still an open research
> problem the last time I looked.

Actually, it's worse than merely an open problem.  A clairvoyant fair scheduler 
with perfect future knowledge can underperform a heuristic fair scheduler, 
because the heuristic scheduler can guess the future incorrectly resulting in 
unfair but higher-throughput behavior.  This is a perfect example of why we only 
try to be as fair as is beneficial.

> Tong's previous trio patch is an attempt at resolving this using a generic
> grouping mechanism and some constructive discussion should come of it.

Sure, but it seems to me to be largely orthogonal to this patch.

	-- Chris
-
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/