Date: Mon, 2 Jul 2001 20:07:58 +0000 (GMT) From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> To: Alfred Perlstein <bright@sneakerz.org> Cc: Julian Elischer <julian@elischer.org>, "Michael C . Wu" <keichii@peorth.iteration.net>, smp@FreeBSD.ORG Subject: Re: per cpu runqueues, cpu affinity and cpu binding. Message-ID: <Pine.LNX.4.20.0107021948020.17878-100000@www.everquick.net> In-Reply-To: <20010702141113.Q84523@sneakerz.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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".
Likewise, a process could say, "Please run these on the same CPU" for
different threads that share much code.
> > 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.
> > 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...
> 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)?
http://www.utc.edu/~jdumas/cs460/papers2000/itanium/Itanium.htm
I just found this via Google, and have only skimmed it... i.e., I can't
comment on the new instruction set, but thought that I'd throw that in.
I _do_ know, however, that the P6 family could be much faster with better
decode and execute units. (Anybody who has ever tuned assembler for the
family knows what I mean...)
Eddy
---------------------------------------------------------------------------
Brotsman & Dreger, Inc.
EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
---------------------------------------------------------------------------
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@brics.com>
To: blacklist@brics.com
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots. Do NOT
send mail to <blacklist@brics.com>, or you are likely to be blocked.
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.LNX.4.20.0107021948020.17878-100000>