sched: implement __set_cpus_allowed()
in [Kernel]
|
Prev: [tip:x86/urgent] x86/mm: Remove unused DBG() macro
Next: sched: consult online mask instead of active in select_fallback_rq()
From: Peter Zijlstra on 31 May 2010 06:20 On Mon, 2010-05-31 at 12:06 +0200, Tejun Heo wrote: > I meant CPU_ONLINE not CPU_UP_PREPARE. So, > we can mark a cpu active before other CPU_ONLINE callbacks are run. OK, that should work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 31 May 2010 06:50 On Mon, 2010-05-31 at 12:19 +0200, Tejun Heo wrote: > Hello, > > On 05/31/2010 12:15 PM, Peter Zijlstra wrote: > > On Mon, 2010-05-31 at 12:06 +0200, Tejun Heo wrote: > >> I meant CPU_ONLINE not CPU_UP_PREPARE. So, > >> we can mark a cpu active before other CPU_ONLINE callbacks are run. > > > > OK, that should work. > > The only remaining problemw is PF_THREAD_BOUND. It needs to be set > for wq workers (including rescuers). Would it be okay to add an > interface which only ignores PF_THREAD_BOUND? So workers _are_ thread bound and don't migrate, so for those I don't see the problem, that is of course until we have to break affinity when their CPU goes down, at which point we should clear PF_THREAD_BOUND I think. For the rescue thread, why not set PF_THREAD_BOUND when its running worklets and clear it when done? That way we get extra checking that people won't migrate it when its not allowed. Does that work, or did I miss something? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 31 May 2010 07:50
Hello, On 05/31/2010 12:46 PM, Peter Zijlstra wrote: > So workers _are_ thread bound and don't migrate, so for those I don't > see the problem, that is of course until we have to break affinity when > their CPU goes down, at which point we should clear PF_THREAD_BOUND I > think. > > For the rescue thread, why not set PF_THREAD_BOUND when its running > worklets and clear it when done? That way we get extra checking that > people won't migrate it when its not allowed. > > Does that work, or did I miss something? The rescuers migrate themselves so should be okay. I still think it would be better to migrate back detached workers. It's a slow path for sure but there's a big gaping hole between machine-slow and human-slow and works can be human-slow (ie. hotplug operation not finished in several minutes). I'll see if that's implementable w/o adding an additional interface. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |