From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756589AbcIHCSC (ORCPT ); Wed, 7 Sep 2016 22:18:02 -0400 Received: from email.kedacom.com ([221.224.36.251]:16761 "EHLO test1.kedacom.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1755008AbcIHCRx (ORCPT ); Wed, 7 Sep 2016 22:17:53 -0400 Subject: Re: [PATCH] sched/core: simpler function for sched_exec migration To: Oleg Nesterov References: <1473056403-7877-1-git-send-email-chengchao@kedacom.com> <20160905131147.GA8552@redhat.com> <20160906152253.GB17586@redhat.com> <89a992af-67cd-91b4-8890-a19ccb251fe6@kedacom.com> <20160907123511.GA1132@redhat.com> Cc: mingo@kernel.org, peterz@infradead.org, tj@kernel.org, akpm@linux-foundation.org, chris@chris-wilson.co.uk, linux-kernel@vger.kernel.org From: chengchao Message-ID: <2543729a-5ec1-dda4-28a6-10522271553e@kedacom.com> Date: Thu, 8 Sep 2016 10:17:48 +0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160907123511.GA1132@redhat.com> X-MIMETrack: Itemize by SMTP Server on kedacomsmtp/kedacom(Release 8.5.3|September 15, 2011) at 2016-09-08 10:17:46, Serialize by Router on kedacomsmtp/kedacom(Release 8.5.3|September 15, 2011) at 2016-09-08 10:17:46, Serialize complete at 2016-09-08 10:17:46, Itemize by SMTP Server on kedacomtest1/kedacom(Release 8.5.3|September 15, 2011) at 2016/09/08 10:17:40, Serialize by Router on kedacomtest1/kedacom(Release 8.5.3|September 15, 2011) at 2016/09/08 10:17:46, Serialize complete at 2016/09/08 10:17:46 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Oled, thank you for moving this patch on. on 09/07/2016 08:35 PM, Oleg Nesterov wrote: > On 09/07, chengchao wrote: >> >> Oleg, thank you very much. >> >> on 09/06/2016 11:22 PM, Oleg Nesterov wrote: >>> On 09/06, chengchao wrote: >>>> >>>> the key point is for CONFIG_PREEMPT_NONE=y, >>>> ... >>>> it is too much overhead for one task(fork()+exec()), isn't it? >>> >>> Yes, yes, I see, this is suboptimal. Not sure we actually do care, >>> but yes, perhaps another helper which migrates the current task makes >>> sense, I dunno. >> >> for CONFIG_PREEMPT_NONE=y, this patch wants the stopper thread can migrate the current >> successfully instead of doing nothing. > > I understand the intent. But I am not sure this optimization makes > sense. > For CONFIG_PREEMPT_NONE=y, when sched_exec() needs migration, sched_exec() calls stop_one_cpu(task_cpu(p), migration_cpu_stop, &arg). If stopper thread can not migrate for us,why should we call stop_one_cpu() here? It just makes the task TASK_UNINTERRUPTIBLE, wakes up the stopper thread, executes the migration_cpu_stop, and the stopper thread wakes up the task. But in fact, all above works are almost unuseful, the reason is that the migration_cpu_stop doesn't migrate for us. why? the migration_cpu_stop() needs the task is TASK_ON_RQ_QUEUED before it calls __migrate_task(). This patch can make the task TASK_RUNNING instead of TASK_UNINTERRUPTIBLE, so the migration_cpu_stop() can migrate happily. Does this optimization make sense now? Any different opinions are always welcome. >> int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, void *arg) >> { >> struct cpu_stop_done done; >> struct cpu_stop_work work = { .fn = fn, .arg = arg, .done = &done }; >> >> cpu_stop_init_done(&done, 1); >> if (!cpu_stop_queue_work(cpu, &work)) >> return -ENOENT; >> >> #if defined(CONFIG_PREEMPT_NONE) >> /* >> * let the stopper thread runs as soon as possible, >> * and keep current TASK_RUNNING. >> */ >> scheudle(); >> #endif >> wait_for_completion(&done.completion); >> return done.ret; >> } > > Agreed this looks better, although I'd suggest _cond_resche(). > > Again, I am not sure this makes sense, I leave this to maintainers. > You have done much works for this patch. Thanks again. > Oleg. > >