[MUD-Dev] Two threads forced to one CPU? (was: Collecting ideas for a MUD server...)
nop at mitre.org
Thu Dec 23 15:29:41 New Zealand Daylight Time 1999
"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
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
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev