Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp3331535ybd; Fri, 28 Jun 2019 06:52:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqxAA6ZOCUK32jwKli7hikNRufTyMq4r9TqyRCqg3vg9TXY1+C1Mh+U9QleuMsYCXVV/rJ5T X-Received: by 2002:a17:90a:b903:: with SMTP id p3mr13156400pjr.79.1561729930006; Fri, 28 Jun 2019 06:52:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561729929; cv=none; d=google.com; s=arc-20160816; b=D7aB2W2pubz29GMXek2NJPg73ZZWczUGZy5tkCaBI72glS5hph5cnkGtLAnOZhzOcw e/jkdSC65dYf+HsmqLI8yTVYai28NSPed4wPP7wiUlpshEm5D8JHGF+fAKoHPO4ZNIPv 0rms7ZJLlfVLlnNDLb+m+DZH2V7DLJd+jQczCGSYjnEoNW5LvVmtlRvTrVgpH/7Ev3tg kO31dVaYRhu08kNA0IzHYWKWX2JgL1STkSXCSJ9uDSrtT0qLQIvT2DESt6qpk/ok8SUG ZBAPdjP8XBHRzdZfCQflR0gcZJb/si9y+bL2dKGkelDOAfHZLi14TRAMBF0q3uOgTQ6c Besw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=B1h1/xipv3BOe7ox5t14uQvL2uoJ0RC2iAUPP1KdAz8=; b=ysxws4BrV3e4kHNX11aDlIXluANRwF5pE/VN05MD5TV3YBNGGGfccBuQzrmX2+Evnz TOuSikB10M1JgmvtnSmkv+2wLCNJY7eStCbpVS7XJMHzrVHiamZ+OruonM2UtvxgpjG1 BG1MygkIpLYe478O6qgnzQK3e4jVMU19T1wFRGkUMmSVJvfIz2Fge4Ajy6WsQDx1gPfK X/MHUt3h5OicgQTNV3WuKywZC1MeZ/8P5i5aE2fajLLuBQCFpmXdVSbQDv55JEpN2hwi y8lI0L22m30gw4xjDZq6GjT3ePn/Rbx8HKLou/MBA05bNEPatdrD98AgV4vAcVX2O+Vv k2fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="L6lw/6Vy"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x9si2144655plv.182.2019.06.28.06.51.53; Fri, 28 Jun 2019 06:52:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="L6lw/6Vy"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726713AbfF1Nvu (ORCPT + 99 others); Fri, 28 Jun 2019 09:51:50 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:38330 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726655AbfF1Nvt (ORCPT ); Fri, 28 Jun 2019 09:51:49 -0400 Received: by mail-lj1-f196.google.com with SMTP id r9so6075675ljg.5 for ; Fri, 28 Jun 2019 06:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B1h1/xipv3BOe7ox5t14uQvL2uoJ0RC2iAUPP1KdAz8=; b=L6lw/6VyDYVWKwP024cpXNGFoM09948dEewrC4H0j+MsEn7WyBbak8cNouPTYGJXtu 0Lha1zJ9POxVPHt/VZv3EwucQN6jW3OTRvya4CKLyxXHBIVObJ4t7yKdoinzARbJsnkq xCeFiUMIj2wwFjBOjlfdR+D/fDsH5DF7mvItjCuBEd9GA2arAcmNDEBkKf4O95nutV8u o2JExRGWNKuCFR7PqvG/hcmFJ1mS+0Ya1SAXCUB1pEEZGXcVYDh6EcjDlXFSno0DzDkR YqcWeVSGYks9Z5f/pnE8fa8s4+okQ5k2WnSTM64AYDfcZmkdV2ehRDmFIrTGHMTq/YHt cdCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B1h1/xipv3BOe7ox5t14uQvL2uoJ0RC2iAUPP1KdAz8=; b=KnT/MNJlauZgi8/Vo3zWKuelTsM9MLwHjTFrsRPBP2U+/vfTBLZyCujlQi7ugCHQkv G9NlBXw/hgR+E5yk7WO+Frfi8KIDWUnjLtPdBXfcRCXI/muOysntg2pvOiljZ1ruFpBi zr4MPw0BoD7QyPe5giBL9kwPAT0VgC2viJ80kXCzvcxj3VobVU0susrx+wH2STrARLg9 dXLHQ2EtSBXoicYCrCICdjFtxny/cDX/2diTPdDEtiwP0vLQejl9iCcYX6yhxomMpoiX TH/YsRIqTHVolcT6rq2Idjg9Rgi0MzVFScFkbic6wCHuqzYnCW6J+SEjXaIGKn6yyfaj Khaw== X-Gm-Message-State: APjAAAVIeq5hwDZ3O0DYU3PyqggetZG+B1vKxP6jllFQ07U/AIwieYw1 pflVdsb4MZace0JKwWDfjdbOI5PBuj4Nfjud4mEZag== X-Received: by 2002:a2e:5b5b:: with SMTP id p88mr6052004ljb.192.1561729907815; Fri, 28 Jun 2019 06:51:47 -0700 (PDT) MIME-Version: 1.0 References: <20190620150555.15717-1-patrick.bellasi@arm.com> <20190628100751.lpcwsouacsi2swkm@e110439-lin> <20190628123800.GS3419@hirez.programming.kicks-ass.net> In-Reply-To: <20190628123800.GS3419@hirez.programming.kicks-ass.net> From: Vincent Guittot Date: Fri, 28 Jun 2019 15:51:36 +0200 Message-ID: Subject: Re: [PATCH] sched/fair: util_est: fast ramp-up EWMA on utilization increases To: Peter Zijlstra Cc: Patrick Bellasi , linux-kernel , Ingo Molnar , "Rafael J . Wysocki" , Viresh Kumar , Douglas Raillard , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Jun 2019 at 14:38, Peter Zijlstra wrote: > > On Fri, Jun 28, 2019 at 11:08:14AM +0100, Patrick Bellasi wrote: > > On 26-Jun 13:40, Vincent Guittot wrote: > > > Hi Patrick, > > > > > > On Thu, 20 Jun 2019 at 17:06, Patrick Bellasi wrote: > > > > > > > > The estimated utilization for a task is currently defined based on: > > > > - enqueued: the utilization value at the end of the last activation > > > > - ewma: an exponential moving average which samples are the enqueued values > > > > > > > > According to this definition, when a task suddenly change it's bandwidth > > > > requirements from small to big, the EWMA will need to collect multiple > > > > samples before converging up to track the new big utilization. > > > > > > > > Moreover, after the PELT scale invariance update [1], in the above scenario we > > > > can see that the utilization of the task has a significant drop from the first > > > > big activation to the following one. That's implied by the new "time-scaling" > > > > > > Could you give us more details about this? I'm not sure to understand > > > what changes between the 1st big activation and the following one ? > > > > We are after a solution for the problem Douglas Raillard discussed at > > OSPM, specifically the "Task util drop after 1st idle" highlighted in > > slide 6 of his presentation: > > > > http://retis.sssup.it/ospm-summit/Downloads/02_05-Douglas_Raillard-How_can_we_make_schedutil_even_more_effective.pdf > > > > So I see the problem, and I don't hate the patch, but I'm still > struggling to understand how exactly it related to the time-scaling > stuff. Afaict the fundamental problem here is layering two averages. The AFAICT, it's not related to the time-scaling In fact the big 1st activation happens because task runs at low OPP and hasn't enough time to finish its running phase before the time to begin the next one happens. This means that the task will run several computations phase in one go which is no more a 75% task. From a pelt PoV, the task is far larger than a 75% task and its utilization too because it runs far longer (even after scaling time with frequency). Once cpu reaches a high enough OPP that enable to have sleep phase between each running phases, the task load tracking comes back to the normal slope increase (the one that would have happen if task would have jump from 5% to 75% but already running at max OPP) > second (EWMA in our case) will always lag/delay the input of the first > (PELT). > > The time-scaling thing might make matters worse, because that helps PELT > ramp up faster, but that is not the primary issue. > > Or am I missing something?