| Message ID | 20121207173950.27305.39499.stgit@srivatsabhat.in.ibm.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On 12/07, Srivatsa S. Bhat wrote: > > Once stop_machine() is gone from the CPU offline path, we won't be able to > depend on local_irq_save() to prevent CPUs from going offline from under us. OK, I guess we need to avoid resched_task()->smp_send_reschedule() after __cpu_disable() and before migrate_tasks(). But, whatever problem we have, > Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline, > while invoking from atomic context. it should be solved, so... > - if (preempt && rq != p_rq) > + if (preempt && rq != p_rq && cpu_online(task_cpu(p))) Why do we need this change? Afaics, you could add BUG_ON(!cpu_online(...)) instead? I am just curious. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/10/2012 01:18 AM, Oleg Nesterov wrote: > On 12/07, Srivatsa S. Bhat wrote: >> >> Once stop_machine() is gone from the CPU offline path, we won't be able to >> depend on local_irq_save() to prevent CPUs from going offline from under us. > > OK, I guess we need to avoid resched_task()->smp_send_reschedule() > after __cpu_disable() and before migrate_tasks(). > Yes. > But, whatever problem we have, > >> Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline, >> while invoking from atomic context. > > it should be solved, so... > >> - if (preempt && rq != p_rq) >> + if (preempt && rq != p_rq && cpu_online(task_cpu(p))) > > Why do we need this change? > > Afaics, you could add BUG_ON(!cpu_online(...)) instead? > > I am just curious. > Oh, I think that's a remnant of v1 (which needed readers to use cpu_online_stable()). You're right, we don't need it. Or we could put a BUG_ON instead, like you suggested. Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/10, Srivatsa S. Bhat wrote: > > On 12/10/2012 01:18 AM, Oleg Nesterov wrote: > >> - if (preempt && rq != p_rq) > >> + if (preempt && rq != p_rq && cpu_online(task_cpu(p))) > > > > Why do we need this change? > > > > Afaics, you could add BUG_ON(!cpu_online(...)) instead? > > > > I am just curious. > > > > Oh, I think that's a remnant of v1 (which needed readers to use > cpu_online_stable()). You're right, we don't need it. Ah OK, thanks. > Or we could put a > BUG_ON instead, like you suggested. IMHO it would be better to simply drop this chunk. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/10/2012 02:10 AM, Oleg Nesterov wrote: > On 12/10, Srivatsa S. Bhat wrote: >> >> On 12/10/2012 01:18 AM, Oleg Nesterov wrote: >>>> - if (preempt && rq != p_rq) >>>> + if (preempt && rq != p_rq && cpu_online(task_cpu(p))) >>> >>> Why do we need this change? >>> >>> Afaics, you could add BUG_ON(!cpu_online(...)) instead? >>> >>> I am just curious. >>> >> >> Oh, I think that's a remnant of v1 (which needed readers to use >> cpu_online_stable()). You're right, we don't need it. > > Ah OK, thanks. > >> Or we could put a >> BUG_ON instead, like you suggested. > > IMHO it would be better to simply drop this chunk. > Sure, will drop it. Its distracting, if nothing else ;-) Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/kernel/sched/core.c b/kernel/sched/core.c index cff7656..4b982bf 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4312,6 +4312,7 @@ bool __sched yield_to(struct task_struct *p, bool preempt) unsigned long flags; bool yielded = 0; + get_online_cpus_atomic(); local_irq_save(flags); rq = this_rq(); @@ -4339,13 +4340,14 @@ again: * Make p's CPU reschedule; pick_next_entity takes care of * fairness. */ - if (preempt && rq != p_rq) + if (preempt && rq != p_rq && cpu_online(task_cpu(p))) resched_task(p_rq->curr); } out: double_rq_unlock(rq, p_rq); local_irq_restore(flags); + put_online_cpus_atomic(); if (yielded) schedule();
Once stop_machine() is gone from the CPU offline path, we won't be able to depend on local_irq_save() to prevent CPUs from going offline from under us. Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline, while invoking from atomic context. Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> --- kernel/sched/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html