Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752728AbdDKJrL (ORCPT ); Tue, 11 Apr 2017 05:47:11 -0400 Received: from mail-oi0-f43.google.com ([209.85.218.43]:33446 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751619AbdDKJrJ (ORCPT ); Tue, 11 Apr 2017 05:47:09 -0400 MIME-Version: 1.0 In-Reply-To: <20170411091219.z26r7sa7hpz7gvix@hirez.programming.kicks-ass.net> References: <1491815909-13345-1-git-send-email-vincent.guittot@linaro.org> <20170410173802.orygigjbcpefqtdv@hirez.programming.kicks-ass.net> <20170411075221.GA30421@linaro.org> <20170411091219.z26r7sa7hpz7gvix@hirez.programming.kicks-ass.net> From: Vincent Guittot Date: Tue, 11 Apr 2017 11:46:48 +0200 Message-ID: Subject: Re: [PATCH v2] sched/fair: update scale invariance of PELT To: Peter Zijlstra Cc: Ingo Molnar , linux-kernel , Dietmar Eggemann , Morten Rasmussen , Yuyang Du , Paul Turner , Ben Segall Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1349 Lines: 29 On 11 April 2017 at 11:12, Peter Zijlstra wrote: > On Tue, Apr 11, 2017 at 09:52:21AM +0200, Vincent Guittot wrote: > >> > > + } else if (!weight) { >> > > + if (sa->util_sum < (LOAD_AVG_MAX * 1000)) { >> > >> > But here I'm completely lost. WTF just happened ;-) >> > >> > Firstly, I think we want a comment on why we care about the !weight >> > case. Why isn't !running sufficient? >> >> We track the time when the task is "really" idle but not the time that >> the task spent to wait for running on the CPU. Running is used to >> detect when the task is really running and how much idle time has been >> lost while weight is used to detect when the task is back to sleep >> state and when we have account the lost idle time. > > Huh? You're redefining what 'idle' means wrt. util_sum. > > util used to consider anything !running as idle. So this is the main > trickery? I feel that deserves a comment of exceptional clarity. So we still decay during runnable but !running state but we don't add the lost idle time of the previous running step yet. We wait the task to go back to sleep before applying the lost idle time in order to not apply the decay of the lost idle time in the middle of a run phase that has been preempted by RT task as an example I will try to make a comment that will explain these details