Date: Mon, 2 Jul 2001 15:03:20 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> Cc: Alfred Perlstein <bright@sneakerz.org>, "Michael C . Wu" <keichii@peorth.iteration.net>, smp@FreeBSD.ORG Subject: Re: per cpu runqueues, cpu affinity and cpu binding. Message-ID: <Pine.BSF.4.21.0107021453160.13213-100000@InterJet.elischer.org> In-Reply-To: <Pine.LNX.4.20.0107021948020.17878-100000@www.everquick.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Jul 2001, E.B. Dreger wrote:
> > Date: Mon, 2 Jul 2001 14:11:13 -0500
> > From: Alfred Perlstein <bright@sneakerz.org>
>
> > > 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
>
> Why force things? Again, going back to affinity hinting... if the hint
> is a composite hash including a process-specified value, that would allow
> a process to say, "Hey, please run these on different CPUs".
There is ABSOLUTLY NO GAIN in allowing it. it only makes things more
difficult to track. They would steal each other's quantum, meaning that
you would not get more CPU time, and since the system calls are all async
in this system you don't get any more concurrency either. There are
different mechanisms (struct #2) to allow you to compete in the scheduler
with greater weight.
>
> Likewise, a process could say, "Please run these on the same CPU" for
> different threads that share much code.
Well then ask the thrtead scheduler to run them on the same CPU (#3)
>
> > > thread scheduler has the ultimate say as to which processor
>
> Not sure that I like this. It would have to be runtime-tunable or modulo
> real number of processors. Then everything wants CPU #0... ick.
No everyhing runs on VIRTUAL CPUs.
the mapping between virtual snd real CPU's is by default not fixed.
Your CPU#0 may not be the same as MY CPU #0.
>
> > > a thread is scheduled on.
> >
> > Actually, this may cause some performance problems, when you have
> > a shared address space you can avoid tlb shootdowns when a process's
> > address space changes, you also share the cache, lastly there's
>
> Example:
>
> task #1 Main program, serving Web requests, processing mail, handling
> database queries, whatever. Needs something {en|de}crypted, so
> it initiates an AIO read for the {de|en}crypted data.
>
> task #2 Performs the {en|de}cryption, then sends process #1 a pointer to
> shared memory containing the result.
>
> In this case, one would want the ability to flag that the processes should
> run on different CPUs. Different critical paths with different code.
> With some of the puny L2 caches nowadays, a task switch on a single
> processor might wipe out L2...
1/ All reads that block will be async (AIO by defualt)
2/ WHich processor #2 runs on depends on
a) where it ran last
b) whether there is a free processor when it get's scheduled, and where it
is.
>
> > some rumor about a new CPU archetecture that runs multple threads
> > on the same CPU at the same time. Just food for thought.
>
> You mean ia64's "explicit parallelism" (EPIC)?
No
"Multiple thread execution units", Separate register files
shared ALUs etc... ALpha was going to try do it..
>
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.0107021453160.13213-100000>