Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753580AbdDKUxJ (ORCPT ); Tue, 11 Apr 2017 16:53:09 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:34643 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753272AbdDKUxH (ORCPT ); Tue, 11 Apr 2017 16:53:07 -0400 MIME-Version: 1.0 In-Reply-To: References: <3498238.liCqOyIkGA@aspire.rjw.lan> <2242635.g1ACnTm5vK@aspire.rjw.lan> From: "Rafael J. Wysocki" Date: Tue, 11 Apr 2017 22:53:06 +0200 X-Google-Sender-Auth: n0-nbOcFLfMCnyt2hCKr9YB5UWE Message-ID: Subject: Re: [RFC/RFT][PATCH 2/2] cpufreq: schedutil: Utilization aggregation To: Joel Fernandes Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Linux PM , Juri Lelli , LKML , Peter Zijlstra , Srinivas Pandruvada , Viresh Kumar , Vincent Guittot , Patrick Bellasi , Morten Rasmussen 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: 1479 Lines: 37 On Tue, Apr 11, 2017 at 3:57 AM, Joel Fernandes wrote: > On Mon, Apr 10, 2017 at 1:59 PM, Rafael J. Wysocki wrote: > [..] >>>> + sg_cpu->util = cfs_util; >>>> + sg_cpu->max = cfs_max; >>>> + } >>>> } >> >> >> Well, that's the idea. :-) >> >> During the discussion at the OSPM-summit we concluded that discarding >> all of the utilization changes between the points at which frequency >> updates actually happened was not a good idea, so they needed to be >> aggregated somehow. >> >> There are a few ways to aggregate them, but the most straightforward >> one (and one which actually makes sense) is to take the maximum as the >> aggregate value. >> >> Of course, this means that we skew things towards performance here, >> but I'm not worried that much. :-) > > Does this increase the chance of going to idle at higher frequency? > Say in the last rate limit window, we have a high request followed by > a low request. After the window closes, by this algorithm we ignore > the low request and take the higher valued request, and then enter > idle. Then, wouldn't we be idling at higher frequency? I guess if you > enter "cluster-idle" then probably this isn't a big deal (like on the > ARM64 platforms I am working on). But I wasn't sure how expensive is > entering C-states at higher frequency on Intel platforms is or if it > is even a concern. :-D It isn't a concern at all AFAICS. Thanks, Rafael