From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754560AbcE3Ja7 (ORCPT ); Mon, 30 May 2016 05:30:59 -0400 Received: from mga01.intel.com ([192.55.52.88]:63321 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754482AbcE3Ja5 (ORCPT ); Mon, 30 May 2016 05:30:57 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,389,1459839600"; d="scan'208";a="112766522" Date: Mon, 30 May 2016 09:33:37 +0800 From: Yuyang Du To: Vincent Guittot Cc: Peter Zijlstra , Ingo Molnar , linux-kernel , Benjamin Segall , Paul Turner , Morten Rasmussen , Dietmar Eggemann , byungchul.park@lge.com Subject: Re: [PATCH 2/2] sched/fair: Skip detach and attach load avgs for new group task Message-ID: <20160530013336.GL18670@intel.com> References: <1464225264-32760-1-git-send-email-yuyang.du@intel.com> <1464225264-32760-3-git-send-email-yuyang.du@intel.com> <20160526194425.GK18670@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vincent, On Fri, May 27, 2016 at 03:37:11PM +0200, Vincent Guittot wrote: > On 26 May 2016 at 21:44, Yuyang Du wrote: > > Hi Vincent, > > > > On Thu, May 26, 2016 at 01:50:56PM +0200, Vincent Guittot wrote: > >> On 26 May 2016 at 03:14, Yuyang Du wrote: > >> > Vincent reported that the first task to a new task group's cfs_rq will > >> > be attached in attach_task_cfs_rq() and once more when it is enqueued > >> > (see https://lkml.org/lkml/2016/5/25/388). > >> > > >> > Actually, it is worse, attach_task_cfs_rq() is called for new task even > >> > way before init_entity_runnable_average(). > >> > > >> > Solve this by avoiding attach as well as detach new task's sched avgs > >> > in task_move_group_fair(). To do it, we need to know whether the task > >> > is forked or not, so we pass this info all the way from sched_move_task() > >> > to attach_task_cfs_rq(). > >> > >> Not sure that this is the right way to solve this problem because you > >> continue to attach the task twice without detaching it in the mean > >> time: > >> - once during the copy of the process in cpu_cgroup_fork (you skip the > >> attach of load average but the task is still attached to the local > >> cpu) > > > > Sorry, the task's what is still attached, and how? You mean the vruntime > > thingy? But the load/util avgs are not. > > yes that's it. The sequence still looks weird IMHO. > the detach is called for a newly forked task that is not fully init > and has not been attached yet > IIUC the fork sequence, we only need to set group at this point so you > can skip completely the detach/attach_task_cfs_rq not only the > detach/attach_entity_load_avg Ok, I previously didn't attempt to touch the vruntime part, because I'm not entirely familiar with it (and never attempted to). Avoiding attach/detach new task in fork indeed makes sense, but I am not sure, Peter, Byungchul? Thanks, Yuyang