> On Mon, Feb 25, 2002 at 02:49:40PM -0500, Bill Davidsen wrote:
> > Unfortunately this is an overly simple view of how SMP works. The only
> > justification for CPU latency is to preserve cache contents. Trying to
> > express this as a single number is bound to produce suboptimal results.
>
> And here is the other side of the coin. Remember what we are doing.
> We're in the middle of a context switch, trying to figure out where we
> should run this process. We would like context switches to be fast.
I hope we're not in the middle of a context switch... hopefully any
decision to move a process is done either (a) during load balancing, or
(b) when you have an idle CPU which needs work to do. Otherwise why
consider changing CPU?
I would think the place to do the work is when it needs doing, not on
every context switch. The CPU selection is costly, as opposed to "which
process to run." Of course when a process moves from blocked to ready it
might be time to consider how long it's been waiting and if anything in
the cache is worth using.
> Any work we do here is at direct odds with our goals. SGI took the
> approach that your statements would imply,
I wasn't really implying anything except the problem being more complex
than "set the affinity to 500ms and tune." You can't tune, the system will
be unresponsive. Since complex decisions would be made infrequently, it
should be better to do them right than to do the wrong thing quickly.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- 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/