Date: Sun, 14 Feb 1999 22:50:02 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Matthew Jacob <mjacob@feral.com> Cc: Jaye Mathisen <mrcpu@internetcds.com>, hackers@FreeBSD.ORG Subject: Re: Processor affinity? Message-ID: <199902150650.WAA12919@apollo.backplane.com> References: <Pine.LNX.4.04.9902142237100.29513-100000@feral-gw>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:
:Really? Hmm.. I would have thought for a machine that with local cache
:but expensive global access (e.g., sun4d architecture) that affinity is a
:win. Oh well, not my area of expertise.
All modern SMP designs have per-cpu caches and nearly all have local
L1 and L2 caches ( because the L2 caches are what tie into the SMP
mechanisms of the backplane ). The expense of a main memory access
verses a cache access is always pretty big.
There are various kinds of SMP caching schemes, but most of the amount
to the same generalities and only differ in their basic performance
characteristic. For example, a number of modern SMP designs use an
L2-read-shared and L2-write-allocate scheme and one L2 cache that misses
is actually able to get the data from another L2 cache belonging to
another cpu rather then have to go to main memory.
The only issue with processor affinity, really, is the actual load on
the main memory. Processor affinity only makes sense when the load on
main memory is relatively high. Typically, SMP systems have a relatively
low main memory load ( and high L1 and L2 cache memory load ), so until
you have enough cpu's banging on the same main memory to saturate it,
processor affinity is usually wash. It makes sense on a big 32+ cpu
Solaris or SGI system, but not much sense on a 2 or 4 cpu system.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199902150650.WAA12919>