I'd asked: Do processes have an "affinity" to a processor on a
multiprocessor system or is scheduling strictly based
on which cpu is available?
Thanks to all who replied, I rec'd lots of interesting and useful info.
Several people talked about pinning a process to a specific cpu:
Rick Morrell said:
Yep... you can "pin" a process to a particular processor by using the
"runon" command. There is also a programming interface which can be used to
do the same thing.. check out the man pages on
assign_cpu_to_pset (3) - Assigns a processor to a processor set
assign_pid_to_pset (3) - Assigns a process identification number to a
processor set
Corinne Haesaerts pointed me to "ps -O SCHED" which gives you a cluster of
options including which processor the job is running on - "PSR".
Oisin McGuinness said:
ps -A -m -O SCHED
will show you threads and processors in use by threads.
There are system calls to set affinity (e.g.,assign_cpu_to_pset) , which
are embodied in the command runon; you can run on a specific processor,
or build up a set of processors, and then runon that set. The affinity
is inherited, you could probably even segregate users on different
processors if need be by runon in .profile....
Do: apropos processor
to see all the possible relevant things. In particular, psradm will let you
stop a processor on the fly....
and Dr. Tom Blinn expanded on the concept:
It depends.. In the more modern kernels, a certain amount of effort
is made to keep a process running on the same processor that it was
running on most recently, because this maximizes cache re-use. But
there is, in general, no strict requirement, and if a process blocks
for any appreciable time, it will get scheduled on any available CPU
unless you are forcing a different policy (e.g., via class scheduler,
if you can figure out how to make it work). In general, there is no
real benefit in restricting some set of processes to particular CPUs,
and in the latest generation system designs, you can probably make
things worse by trying to do so if you don't really understand all of
the underlying issues and the default algorithms.
Thanks again, and kudos to this great list.
--
Judith Reed
jreed_at_appliedtheory.com
(315) 453-2912 x5835
Received on Wed Jul 26 2000 - 15:15:52 NZST