lkml.org 
[lkml]   [2007]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] scheduler: improve SMP fairness in CFS
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-07-24 23:27    [W:0.242 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site