From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753949AbcFPJmg (ORCPT ); Thu, 16 Jun 2016 05:42:36 -0400 Received: from mail-lf0-f47.google.com ([209.85.215.47]:34675 "EHLO mail-lf0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751562AbcFPJme (ORCPT ); Thu, 16 Jun 2016 05:42:34 -0400 MIME-Version: 1.0 In-Reply-To: <20160615232453.GN8105@intel.com> References: <1464623541-25429-1-git-send-email-vincent.guittot@linaro.org> <20160615191914.GM8105@intel.com> <20160615232453.GN8105@intel.com> From: Vincent Guittot Date: Thu, 16 Jun 2016 11:42:12 +0200 Message-ID: Subject: Re: [PATCH v3] sched: fix first task of a task group is attached twice To: Yuyang Du Cc: Peter Zijlstra , Ingo Molnar , linux-kernel , Dietmar Eggemann Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16 June 2016 at 01:24, Yuyang Du wrote: > On Thu, Jun 16, 2016 at 09:12:58AM +0200, Vincent Guittot wrote: >> > Then, when enqueued, both cfs_rq and task will be decayed to 0, due to >> > a large gap between 1 and now, no? >> >> yes, like it is done currently (but 1ns later) . > > Well, currently, cfs_rq will be decayed to 0, but will then add the task. > So it turns out the current result is right. Attached twice, but result > is right. Correct? So the load looks accidentally correct but not the utilization which will be overestimated up to twice the max With this change,the behavior of the 1st task becomes the same as what happen to the other tasks that will be attached to the task group that has been idle for a while and that has an old last_update_time. Then, i have other pending patch to fix this behavior, has mentioned in a previous email