lkml.org 
[lkml]   [2002]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch] scheduler, migration startup fixes, 2.5.29
Date
In message <Pine.LNX.4.44.0207271254200.13591-100000@localhost.localdomain> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.049 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site