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.