Re: [patch] scheduler, migration startup fixes, 2.5.29

[Rusty Russell]

In message <[e-mail]> you
 write:
> 
> the attached patch fixes the scheduler's migration thread startup bug that
> got unearthed by Rusty's recent CPU-startup enhancements.
> 
> the fix is to let a startup-helper thread migrate the migration thread,
> instead of the migration thread calling set_cpus_allowed() itself.  
> Migrating a not running thread is a simple and robust thing, and needs no
> cooperation from migration threads - thus the catch-22 problem of how to
> migrate the migration threads is solved finally.
> 
> the patch is against Rusty's initcall fix/hack which calls
> migration_init() before other CPUs are brought up - this ordering is
> clearly the clean way of doing migration init. [the patch also fixes a UP
> compiliation bug in Rusty's hack.]
> 
> tested on x86 SMP and UP.

This is, AFAICT, overkill (the UP compilation fix appreciated though).

When a new CPU comes up, there is a semaphore which is held through
the notifier, so you can't have two CPUs come up at once.

Therefore, the new migration thread is either started on a completely
active cpu (ie. there's a migration thread on that CPU to use), or
it's already on the new cpu, in which case set_cpus_allowed is a noop.

What am I missing?
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.