Skip site navigation (1)Skip section navigation (2)
Date:      15 Feb 1999 21:03:09 +0200
From:      Ville-Pertti Keinonen <will@iki.fi>
To:        dyson@iquest.net
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Processor affinity?
Message-ID:  <864sonmqvm.fsf@not.oeno.com>
In-Reply-To: dyson@iquest.net's message of "15 Feb 1999 09:46:22 %2B0200"
References:  <199902150650.WAA12919@apollo.backplane.com> <199902150744.CAA00356@y.dyson.net>

next in thread | previous in thread | raw e-mail | index | archive | help

dyson@iquest.net (John S. Dyson) writes:

> # of active CPU cycles.  I do have affinity code for SMP, and it makes
> a positive difference in performance, even with the big-lock FreeBSD kernel.

What does it do?

In order to be more useful than a last-run-on hint (which is pretty
much useless for time-sharing), it needs to be able to select a
thread that doesn't have the highest priority to run when the best
processor for the highest-priority runnable (but not active) thread
is (momentarily) running a even higher-priority thread.

Doing something like this in a BSD scheduler is a bit difficult
because of the priority buckets.  It seems to me that you either
give up O(1) thread selection (the Linux folks seem to be happy
with O(n), but I don't like the idea) or have to do something
moderately complex (such as per-processor run queues with load
balancing, like DEC did with OSF/1).

Or did you find a more elegant solution?

> The reason for diminishing gains on a 2 or 4 cpu system isn't bandwidth as
> much as it is the availability of fewer CPUs to choose from.  By blindly
> choosing the wrong cpu, there will be much more latency assocated with
> refilling the cache on context switch.

And with affinity, particularly if it is too strong, you'll
occasionally have far more latency associated with getting a thread
to run again when the right cpu wasn't available when the thread
would "naturally" have run.

I suspect that DEC's scheme does this too easily to interactive
threads, but haven't done any real testing.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?864sonmqvm.fsf>