From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757738AbcCCTOk (ORCPT ); Thu, 3 Mar 2016 14:14:40 -0500 Received: from foss.arm.com ([217.140.101.70]:39348 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753213AbcCCTOj (ORCPT ); Thu, 3 Mar 2016 14:14:39 -0500 Subject: Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data To: Peter Zijlstra References: <2495375.dFbdlAZmA6@vostro.rjw.lan> <1842158.0Xhak3Uaac@vostro.rjw.lan> <20160303153817.GO6344@twins.programming.kicks-ass.net> <20160303162829.GB6375@twins.programming.kicks-ass.net> <56D87457.1050600@arm.com> <20160303182624.GU6356@twins.programming.kicks-ass.net> Cc: Vincent Guittot , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Linux PM list , Juri Lelli , Steve Muckle , ACPI Devel Maling List , Linux Kernel Mailing List , Srinivas Pandruvada , Viresh Kumar , Michael Turquette From: Dietmar Eggemann Message-ID: <56D88D1B.7060309@arm.com> Date: Thu, 3 Mar 2016 19:14:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160303182624.GU6356@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/03/16 18:26, Peter Zijlstra wrote: > On Thu, Mar 03, 2016 at 05:28:55PM +0000, Dietmar Eggemann wrote: >>> +void arch_scale_freq_tick(void) >>> +{ >>> + u64 aperf, mperf; >>> + u64 acnt, mcnt; >>> + >>> + if (!static_cpu_has(X86_FEATURE_APERFMPERF)) >>> + return; >>> + >>> + aperf = rdmsrl(MSR_IA32_APERF); >>> + mperf = rdmsrl(MSR_IA32_APERF); >>> + >>> + acnt = aperf - this_cpu_read(arch_prev_aperf); >>> + mcnt = mperf - this_cpu_read(arch_prev_mperf); >>> + >>> + this_cpu_write(arch_prev_aperf, aperf); >>> + this_cpu_write(arch_prev_mperf, mperf); >>> + >>> + this_cpu_write(arch_cpu_freq, div64_u64(acnt * SCHED_CAPACITY_SCALE, mcnt)); >> >> Wasn't there the problem that this ratio goes to zero if the cpu is idle >> in the old power estimation approach on x86? > > Yeah, there was something funky. > > SDM says they only count in C0 (ie. !idle), so it _should_ work. I see, back than the problem was 0 capacity in idle but this is about frequency.