From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Muckle Subject: Re: [PATCH v2 3/3] cpufreq: schedutil: map raw required frequency to driver frequency Date: Mon, 30 May 2016 09:48:33 -0700 Message-ID: <20160530164833.GH9864@graphite.smuckle.net> References: <1464231181-30741-1-git-send-email-smuckle@linaro.org> <1464231181-30741-4-git-send-email-smuckle@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from mail-pf0-f172.google.com ([209.85.192.172]:32810 "EHLO mail-pf0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161656AbcE3Qsh (ORCPT ); Mon, 30 May 2016 12:48:37 -0400 Received: by mail-pf0-f172.google.com with SMTP id b124so65978140pfb.0 for ; Mon, 30 May 2016 09:48:37 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Wanpeng Li Cc: Steve Muckle , Peter Zijlstra , Ingo Molnar , "Rafael J. Wysocki" , Viresh Kumar , "linux-kernel@vger.kernel.org" , Linux PM list , Vincent Guittot , Morten Rasmussen , Dietmar Eggemann , Juri Lelli , Patrick Bellasi , Michael Turquette On Fri, May 27, 2016 at 01:41:02PM +0800, Wanpeng Li wrote: > 2016-05-26 10:53 GMT+08:00 Steve Muckle : > > The slow-path frequency transition path is relatively expensive as it > > requires waking up a thread to do work. Should support be added for > > remote CPU cpufreq updates that is also expensive since it requires an > > IPI. These activities should be avoided if they are not necessary. > > > > To that end, calculate the actual driver-supported frequency required by > > the new utilization value in schedutil by using the recently added > > cpufreq_driver_resolve_freq callback. If it is the same as the > > previously requested driver frequency then there is no need to continue > > with the update assuming the cpu frequency limits have not changed. This > > will have additional benefits should the semantics of the rate limit be > > changed to apply solely to frequency transitions rather than to > > frequency calculations in schedutil. > > sugov_should_update_freq() still be called before get_nex_freq() after > the patch applied, so rate limit still apply to both frequency > transitions and frequency calculations, right? Yes this series does not change the semantics of the rate limit. It only includes the changes required for resolving raw target frequencies to driver-supported frequencies so redundant operations can be avoided. FWIW the approach I took to change the rate_limit semantics [0] just moves where last_freq_update_time is set. I was going to return to that once these changes are complete. [0]: https://lkml.org/lkml/2016/5/9/857 thanks, Steve