[MUD-Dev] Two threads forced to one CPU? (was: Collecting ideas for a MUD server...)

[Jay Carlson]

"J C Lawrence" <claw at kanga.nu> writes:


> On Thu, 23 Dec 1999 01:40:44 -0800 (PST)
> Wesley W Terpstra <terpstra at iota.dhs.org> wrote:
>
> > You're saying if I spawn two threads and having both work nonstop
> > the OS won't put them on different CPUs?
>
> Not necessarily.  Further, very few OSes support runtime thread
> migration (IRIX is one of the few FWIW).

[..]

>   If you have say a 2-way box with a single process hogging one CPU,
> and the second CPU mostly free, new threads are most likely to be
> assigned to the second CPU.  This is reasonable.  Now let's say that
> the hoggy process dies, leaving the second CPU hogged with threads
> and the first entirely idle.
>
>   Under most current OSes nothing changes.  All the threads continue
> execution on the CPU they were originally assigned and the first CPU
> remains idle.  Future thread and process starts will likely be
> assigned to the firt CPU, but if there are none it will remain idle.
> Some OSes, and they are very few, will dynamically migrate threads
> between CPUs (and even between nodes in a cluster in some cases (cf
> IRIX CC:NUMA)) at runtime to best use available resources.

I think you need to go reread /usr/src/linux/kernel/sched.c, unless you're
already counting Linux as one of the "very few".  Linux is quite willing to
move processes between CPUs in an SMP box.  There is a minor bias in favor
of keeping a process assigned to the same CPU, but the current feeling is
that stalling a process to hopefully get a warm cache on its previous CPU is
a waste.

Come to think of it, Solaris 7 on sparc hardware is reassigning processors
for the /usr/local/bin/top process I'm running right now, every fifteen
seconds or so.

Migration between nodes in a cluster, yes, very few operating systems do
that.

Jay






_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev