lkml.org 
[lkml]   [2015]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[PATCH 0/3] (Was: sched: start stopper early)
To avoid the confusion, this has nothing to do with "stop_machine"
changes we discuss in another thread, but

On 10/09, Oleg Nesterov wrote:
>
> > case CPU_ONLINE:
> > + stop_machine_unpark(cpu);
> > /*
> > * At this point a starting CPU has marked itself as online via
> > * set_cpu_online(). But it might not yet have marked itself
> > @@ -5337,7 +5340,7 @@ static int sched_cpu_active(struct notifier_block *nfb,
> > * Thus, fall-through and help the starting CPU along.
> > */
> > case CPU_DOWN_FAILED:
> > - set_cpu_active((long)hcpu, true);
> > + set_cpu_active(cpu, true);
>
> On a second thought, we can't do this (and your initial change has
> the same problem).
>
> We can not wakeup it before set_cpu_active(). This can lead to the
> same problem fixed by dd9d3843755da95f6 "sched: Fix cpu_active_mask/
> cpu_online_mask race".

OTOH, I don't understand why do we actually need this fix... Or, iow
I don't really understand the cpu_active() checks in select_fallback_rq().

Looks like we have some strange arch/ which has the "unsafe" online &&
!active window, but then it is not clear why it is safe to mark it active
in sched_cpu_active(CPU_ONLINE). Confused.

And I am even more confused by the fact that select_fallback_rq()
checks cpu_active(), but select_task_rq() doesn't. This can't be right
in any case.

Oleg.


kernel/sched/core.c | 41 +++++++++++++++++++++--------------------
1 files changed, 21 insertions(+), 20 deletions(-)



\
 
 \ /
  Last update: 2015-10-10 21:21    [W:0.145 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site