Re: process flips between CPUs

[Matthew Dillon]

A process which is sleeping most of the time will tend to be scheduled
on whatever cpu is available.  From the perspective of the scheduler
which may switch between user processes on a 1/100 second clock a
process which uses the cpu heavily will tend to be scheduled on the
same cpu.  However, from the human perspective observing the top or ps
output, even a heavily cpu-bound program will switch between cpus every
so often.

Normally locking a process to a particular cpu is not necessary.

-Matt

Re: process flips between CPUs

[Chris Turner]

On 08/18/11 21:29, Pierre Abbat wrote:

I'm recompiling world (and later kernel, to fix the Linux emul bug) and
watching top. The tor process keeps the same pid, but sometimes it's in CPU 1
and sometimes in CPU 0. How come? Also, besides programs in state RUN,
there's often one in CPU0 and one in CPU1. What does this mean?


This is by design - processes which need to run are scheduled to available CPU 
resources
which might change depending on other processes being activated. There is some 
scheduler
code to manage migrations but I don't recall the specifics of when this 
does/does not happen -
the parameters/penalty of switching vs not switching being either the cost of 
migrating
available CPU cache / process state vs waiting for the current processor 
becoming available.

The technical term for keeping one process assigned to a single processor is 
called 'cpu affinity' -
we have such a feature in the usched_set(2) library function but I don't think 
there is an easy
userland tool (a la nice(1), ioprio(1), rtprio(1), etc) to launch programs 
using this feature, though
it should be fairly trivial to set this up assuming the assignment is kept 
across fork/exec calls -
I defer to the cpu-affinity gurus on this for the time being.. :D

as for the processor states being RUN on 2x CPU's - thats because if you have N 
CPU's, N programs
can be running at once, one on each cpu.

process flips between CPUs

[Pierre Abbat]

I'm recompiling world (and later kernel, to fix the Linux emul bug) and 
watching top. The tor process keeps the same pid, but sometimes it's in CPU 1 
and sometimes in CPU 0. How come? Also, besides programs in state RUN, 
there's often one in CPU0 and one in CPU1. What does this mean?

Pierre
-- 
gau do li'i co'e kei do