On 09/09, Cheng Chao wrote: > > If the migration_cpu_stop() can not migrate,why do we call stop_one_cpu()? > It just makes the task TASK_UNINTERRUPTIBLE, wakes up the stopper thread, > executes migration_cpu_stop(), and the stopper thread wakes up the task.
and this finally migrates the target, ttwu() does another select_task_rq(). > This patch keeps the task TASK_RUNNING instead of TASK_UNINTERRUPTIBLE, > so the migration_cpu_stop() can do useful works. yes, this avoids the extra wakeup/select_task_rq. So this is the minor optimization. > Signed-off-by: Cheng Chao <chengc...@kedacom.com> > --- > kernel/stop_machine.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c > index 4a1ca5f..41aea5e 100644 > --- a/kernel/stop_machine.c > +++ b/kernel/stop_machine.c > @@ -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(); Well. This can help in general, wait_for_completion() won't block, but only if we queue the work on the same CPU. Otherwise this schedule() adds the unnecessary pessimization. That is why I suggested to use _cond_resched() instead of schedule(). But let me repeat, I leave this to maintainers. Oleg.
