Mike is right, the idle task is not included in any of the
runqueues. It's priority is MAX_PRIO, while the queues have the
indices 0 ... MAX_PRIO-1. I didn't find any place in the code where
the "array" element of an idle task is set to something else than
NULL. The idle task is either the current task (in which case it
cannot be stolen) or not in the runqueues.
If you don't trust it, an architecture independent way of setting the
cpus_allowed mask is in the init_idle() routine, just before the
I'd be curious to know which kernel you used and what scheduler
relevant patches you eventually had on top of it.
On Friday 13 December 2002 20:43, Mike Kravetz wrote:
> On Fri, Dec 13, 2002 at 11:04:49AM -0800, John Hawkes wrote:
> > It would appear that the idle thread's "cpus_allowed" field is
> > uninitialized (and defaults to 0xffffffff) for i386 and badly
> > initialized for ia64 (at least for our SGI SN systems), rather than
> > being initialized to pin each idle thread to its specific CPU. The
> > effect of that is that the scheduler's load_balance() algorithm will
> > chose an idle thread to migrate if the "busiest" CPU is busy with
> > processes that are pinned to that CPU and thus cannot move.
> It has been a while since I looked at the scheduler code, but I
> seem to remember that idle threads did not reside on the runqueues.
> As such, they would not be subject to load balancing. Can anyone
> verify or deny this? If not I'll take a look at the code.
> Are you actually seeing idle threads migrate, or is your concern
> based on the uninitialized cpus_allowed fields?