Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Jul 2001 13:19:04 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        "Michael C . Wu" <keichii@peorth.iteration.net>
Cc:        "E.B. Dreger" <eddy+public+spam@noc.everquick.net>, Alfred Perlstein <bright@sneakerz.org>, smp@FreeBSD.ORG
Subject:   Re: per cpu runqueues, cpu affinity and cpu binding.
Message-ID:  <Pine.BSF.4.21.0107021303460.13213-100000@InterJet.elischer.org>
In-Reply-To: <20010702115044.C99436@peorth.iteration.net>

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


On Mon, 2 Jul 2001, Michael C . Wu wrote:

> On Mon, Jul 02, 2001 at 04:42:51PM +0000, E.B. Dreger scribbled:
> | 
> | Not just keeping a given process on the same CPU... but what about a
> | "process type"?  i.e., if different processes have the same ELF header,
> | run them _all_ on the CPU _unless_ it leaves another CPU excessively idle.
> | 
> | Why waste [code] cache on multiple processors when you can keep things on
> | one?
> 
> Because it is very difficult to worry about these things. And the performance
> gain might probably be less than the overhead of comparing the headers.

One could note a prefered processor in the vnode of the executable
exec() could take note of this and switch processors if the load
balancing algorythm showed that the new processor would not become
overly stresssed at the idea. (do all /bin/sh run on the sme processor?)
or maybe the vnode can note which processors it is already on (more than
one). 

> 
> | > I don't think doing per-thread affinity is a good idea.  Because
> | > we want to keep threads lightweight.
> | 
> | !!!
> 
> Please elaborate.  I don't understand what three exclamation marks
> are supposed to mean.

At USENIX we decided to proceed with the KSE work.
I have already re-implemented the proc-splitting patches from January and 
have split the proc structure into parts to support threads. In this case
teh processor affinity stuff that alfred has done are already in a
per-thread (per kse) basis. Individual threads may migrate between KSEs
but if teh program acts to implement KSEs (thread carriers) on multiple
processors then they will try STAY on particular processors.

As a side issue I plan on NOT ALLOWING multiple KSEs (thread carriers?)
from the same thread group in the same process to be on the same
processor. SO load balancing and processor affinity will not
apply to the thread-carrying entities (KSEs). Of course the userland
thread scheduler has the ultimate say as to which processor
a thread is scheduled on.

> 

julian


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0107021303460.13213-100000>