on 09/12/2016 07:03 PM, Oleg Nesterov wrote: > On 09/10, Cheng Chao wrote: >> >> @@ -126,6 +126,17 @@ int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, >> void *arg) >> cpu_stop_init_done(&done, 1); >> if (!cpu_stop_queue_work(cpu, &work)) >> return -ENOENT; >> + >> +#if defined(CONFIG_PREEMPT_NONE) >> + /* >> + * Makes the stopper thread run as soon as possible. >> + * And if the caller is TASK_RUNNING, keeps the caller TASK_RUNNING. >> + * It's special useful for some callers which are expected to be >> + * TASK_ON_RQ_QUEUED. >> + * sched_exec does benefit from this improvement. >> + */ >> + schedule(); >> +#endif >> wait_for_completion(&done.completion); >> return done.ret; >> } > > Cheng, I already tried twice to suggest to conditionalize this schedule, > because it can only help if cpu == smp_processor_id, and you didn't reply. > I still think _cond_resched() makes more sense. > > I won't really argue if you prefer it this way. But did you see my emails? >
I read them, thanks. because Peter didn't receive my mails before, it took me much time to fix my mailbox, so I didn't reply on time. Ok, even if cpu != smp_processor_id(), to call schedule() instead _cond_resched() can give the caller a chance not to sleep. when the caller runs on the cpu again, it may likely find the completion is already done. then the stopper thread cpu_stop_signal_done() and the caller wait_for_completion() will actually run very soon. I think it is trivial improvement. using cond_resched()/_cond_resched() is better for readability, I choose the cond_resched(). thanks again. > Oleg. >
