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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 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 DDC41C4CEC9 for ; Tue, 17 Sep 2019 14:21:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AECB221852 for ; Tue, 17 Sep 2019 14:21:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727673AbfIQOVp (ORCPT ); Tue, 17 Sep 2019 10:21:45 -0400 Received: from mx2.suse.de ([195.135.220.15]:50560 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725922AbfIQOVp (ORCPT ); Tue, 17 Sep 2019 10:21:45 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 544B3AF0D; Tue, 17 Sep 2019 14:21:43 +0000 (UTC) Message-ID: <1568730426.3329.3.camel@suse.cz> Subject: Re: [PATCH 1/2] x86,sched: Add support for frequency invariance From: Giovanni Gherdovich To: Srinivas Pandruvada , tglx@linutronix.de, mingo@redhat.com, peterz@infradead.org, bp@suse.de, lenb@kernel.org, rjw@rjwysocki.net Cc: x86@kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, mgorman@techsingularity.net, matt@codeblueprint.co.uk, viresh.kumar@linaro.org, juri.lelli@redhat.com, pjt@google.com, vincent.guittot@linaro.org, qperret@qperret.net, dietmar.eggemann@arm.com Date: Tue, 17 Sep 2019 16:27:06 +0200 In-Reply-To: <4226d5f460604a8130f8079b74ef3fb1d60009d7.camel@linux.intel.com> References: <20190909024216.5942-1-ggherdovich@suse.cz> <20190909024216.5942-2-ggherdovich@suse.cz> <4226d5f460604a8130f8079b74ef3fb1d60009d7.camel@linux.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org 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). 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