From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34CC3C4CECD for ; Tue, 17 Sep 2019 15:56:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 07F67214AF for ; Tue, 17 Sep 2019 15:56:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="LWAM28RJ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730115AbfIQPzo (ORCPT ); Tue, 17 Sep 2019 11:55:44 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:40879 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730104AbfIQPzo (ORCPT ); Tue, 17 Sep 2019 11:55:44 -0400 Received: by mail-lf1-f65.google.com with SMTP id d17so3306296lfa.7 for ; Tue, 17 Sep 2019 08:55:43 -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=IaYBjBB2ciR2FZbasZb6pweK9GCwJkoOMmn4LHV+BHQ=; b=LWAM28RJdpsodjhvi9CY2qESRcdr9tSPL6P3lrcUVSuIeDJ2fOTBvd42az3X0wqS4f xFUoxTyUjfcVx0AlrPJ25NGRr5jtU+7Db/ymeP4WHLUosTGAykZY2IGKEtA9EG+e7/6H hMBTdO1/WocsA3vnU31M55/2AlKK+dZVyWprCxBks2YDTZZ4OtLJw+zEAbp+Y2v/1C5z onvtCwzlUYtQs2yzh54yoPmUFarfEZ78zNgDKQl2AOO39cGvemeDZEuB6I5koiTEsMY0 gTPjBHF+LRRu+xcKmsW2WFfkZttcGMdYqKweHOt4j16mbRYn3XrWB86glKBTiYUunDZJ MCNg== 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=IaYBjBB2ciR2FZbasZb6pweK9GCwJkoOMmn4LHV+BHQ=; b=sFs4P4IxZ9HYniZ4MEnH45CtvcGtK+XdhMEAlZX5gbG8bu5ULAElMqLe/nAI2beGlr vprhy8maGJ0U40bCvq6V0oKRGHiNKB9YmK1JyH1yJWvnMNCsGFvx+jw9NAUfOH5DnYxE yxtWYql5xNcweMPfMLbkXbo+o4pUYEQivwifad6Ls6l73AOKK0a3z2e79g8cUpzbideP PqAtVEsVVpuRwGlzJAYQVFmGajGt4etvJ11GSxDOhqfi+GAq+4TEga7nZ+abHEsjlUEG S00DpFGeP1SHZGI2iqf+rxs+C1RYRBuFwuE/hjpe2TfbSN0znCHFBpeY1Viwo2R8fh4y 6hrg== X-Gm-Message-State: APjAAAUcBJn4WhX73KucjgkhqhgZcjNT52GOevIRpo6BdLI+6K20eRS0 BR5BjQonHTHnb6tFRC/Cwn4TJlp33YnH3FG0l23MBw== X-Google-Smtp-Source: APXvYqwoToHg7oUESjS5k4c81wnsFbGwws0kecvhdMQKJi+gLMp4KU7pTyRkDPLtkp1xV18DEbEuOTDxJ4rVe/GsbMo= X-Received: by 2002:ac2:5203:: with SMTP id a3mr2437460lfl.151.1568735742321; Tue, 17 Sep 2019 08:55:42 -0700 (PDT) MIME-Version: 1.0 References: <20190909024216.5942-1-ggherdovich@suse.cz> <20190909024216.5942-2-ggherdovich@suse.cz> <4226d5f460604a8130f8079b74ef3fb1d60009d7.camel@linux.intel.com> <1568730426.3329.3.camel@suse.cz> In-Reply-To: <1568730426.3329.3.camel@suse.cz> From: Vincent Guittot Date: Tue, 17 Sep 2019 17:55:29 +0200 Message-ID: Subject: Re: [PATCH 1/2] x86,sched: Add support for frequency invariance To: Giovanni Gherdovich Cc: Srinivas Pandruvada , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , bp@suse.de, "Cc: Len Brown" , "Rafael J. Wysocki" , x86@kernel.org, "open list:THERMAL" , linux-kernel , Mel Gorman , Matt Fleming , viresh kumar , Juri Lelli , Paul Turner , qperret@qperret.net, Dietmar Eggemann Content-Type: text/plain; charset="UTF-8" Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Tue, 17 Sep 2019 at 16:21, Giovanni Gherdovich wrote: > > Hello Srinivas, > > On Fri, 2019-09-13 at 15:52 -0700, Srinivas Pandruvada wrote: > > On Mon, 2019-09-09 at 04:42 +0200, Giovanni Gherdovich wrote: > > > > ... > > > > > + > > > +/* > > > + * APERF/MPERF frequency ratio computation. > > > + * > > > + * The scheduler wants to do frequency invariant accounting and > > > needs a <1 > > > + * ratio to account for the 'current' frequency, corresponding to > > > + * freq_curr / freq_max. > > > > I thought this is no longer the restriction and Vincent did some work > > to remove this restriction. > > If you're referring to the patch > > 23127296889f "sched/fair: Update scale invariance of PELT" > > merged in v5.2, I'm familiar with that and from my understanding you still > want a <1 scaling factor. This is my recalling of the patch: > > Vincent was studying some synthetic traces and realized that util_avg reported > by PELT didn't quite match the result you'd get computing the formula with pen > and paper (theoretical value). To address this he changed where the scaling > factor is applied in the PELT formula. > > At some point when accumulating the PELT sums, you'll have to measure the time > 'delta' since you last updated PELT. What we have after Vincent's change is > that this time length 'delta' gets itself scaled by the freq_curr/freq_max > ratio: > > delta = time since last PELT update > delta *= freq_percent > > In this way time goes at "wall clock speed" only when you're running at max > capacitiy, and goes "slower" (from the PELT point of view) if we're running at > a lower frequency. I don't think Vincent had in mind a faster-than-wall-clock > PELT time (which you'd get w/ freq_percent>1). Yes, I haven't really planned to have time going faster that wall clock but I don't see any algorithm problem at least if that would be the case. There will be a reduced maximum delta update of clock pelt but that will still be large enough > > Speaking of which, Srinivas, do you have any opinion and/or requirement about > this? I confusely remember Peter Zijlstra saying (more than a year ago, now) > that you would like an unclipped freq_curr/freq_max ratio, and may not be > happy with this patch clipping it to 1 when freq_curr > 4_cores_turbo. If > that's the case, could you elaborate on this? > Ignore that if it doesn't make sense, I may be mis-remembering. > > > Thanks, > Giovanni