From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755855AbdGLJ2D (ORCPT ); Wed, 12 Jul 2017 05:28:03 -0400 Received: from mail-pf0-f169.google.com ([209.85.192.169]:33227 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750738AbdGLJ17 (ORCPT ); Wed, 12 Jul 2017 05:27:59 -0400 Date: Wed, 12 Jul 2017 14:57:55 +0530 From: Viresh Kumar To: Peter Zijlstra Cc: Dietmar Eggemann , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Linux Kernel Mailing List , Linux PM , Russell King - ARM Linux , Greg Kroah-Hartman , Russell King , Catalin Marinas , Will Deacon , Juri Lelli , Vincent Guittot , Morten Rasmussen Subject: Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support Message-ID: <20170712092755.GD1679@vireshk-i7> References: <20170706094948.8779-1-dietmar.eggemann@arm.com> <22f004af-0158-8265-2da5-34743f294bfb@arm.com> <12829054.TWIodSo4bb@aspire.rjw.lan> <20170711060106.GL2928@vireshk-i7> <45224055-7bf1-243b-9366-0f2d3442ef59@arm.com> <20170712040917.GG17115@vireshk-i7> <20170712083125.at7jic63ozoxoqap@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170712083125.at7jic63ozoxoqap@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12-07-17, 10:31, Peter Zijlstra wrote: > So the problem with the thread is two-fold; one the one hand we like the > scheduler to directly set frequency, but then we need to schedule a task > to change the frequency, which will change the frequency and around we > go. > > On the other hand, there's very nasty issues with PI. This thread would > have very high priority (otherwise the SCHED_DEADLINE stuff won't work) > but that then means this thread needs to boost the owner of the i2c > mutex. And that then creates a massive bandwidth accounting hole. > > > The advantage of using an interrupt driven state machine is that all > those issues go away. > > But yes, whichever way around you turn things, its crap. But given the > hardware its the best we can do. Thanks for the explanation Peter. IIUC, it will take more time to change the frequency eventually with the interrupt-driven state machine as there may be multiple bottom halves involved here, for supply, clk, etc, which would run at normal priorities now. And those were boosted currently due to the high priority sugov thread. And we are fine with that (from performance point of view) ? Coming back to where we started from (where should we call arch_set_freq_scale() from ?). I think we would still need some kind of synchronization between cpufreq core and the cpufreq drivers to make sure we don't start another freq change before the previous one is complete. Otherwise the cpufreq drivers would be required to have similar support with proper locking in place. And if the core is going to get notified about successful freq changes (which it should IMHO), then it may still be better to call arch_set_freq_scale() from the core itself and not from individual drivers. -- viresh