From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752431AbdCPMoJ (ORCPT ); Thu, 16 Mar 2017 08:44:09 -0400 Received: from foss.arm.com ([217.140.101.70]:33208 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752394AbdCPMoH (ORCPT ); Thu, 16 Mar 2017 08:44:07 -0400 Date: Thu, 16 Mar 2017 12:44:20 +0000 From: Juri Lelli To: Patrick Bellasi Cc: Joel Fernandes , "Joel Fernandes (Google)" , Linux Kernel Mailing List , linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Andres Oportus Subject: Re: [RFC v3 5/5] sched/{core,cpufreq_schedutil}: add capacity clamping for RT/DL tasks Message-ID: <20170316124420.GQ31499@e106622-lin> References: <1488292722-19410-6-git-send-email-patrick.bellasi@arm.com> <20170315114052.GB18557@e110439-lin> <20170315144449.GH31499@e106622-lin> <20170315162414.GI31499@e106622-lin> <20170316111644.GP31499@e106622-lin> <20170316122726.GA10171@e110439-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170316122726.GA10171@e110439-lin> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/03/17 12:27, Patrick Bellasi wrote: > On 16-Mar 11:16, Juri Lelli wrote: > > On 15/03/17 16:40, Joel Fernandes wrote: > > > On Wed, Mar 15, 2017 at 9:24 AM, Juri Lelli wrote: > > > [..] > > > > > > > >> > However, trying to quickly summarize how that would work (for who is > > > >> > already somewhat familiar with reclaiming bits): > > > >> > > > > >> > - a task utilization contribution is accounted for (at rq level) as > > > >> > soon as it wakes up for the first time in a new period > > > >> > - its contribution is then removed after the 0lag time (or when the > > > >> > task gets throttled) > > > >> > - frequency transitions are triggered accordingly > > > >> > > > > >> > So, I don't see why triggering a go down request after the 0lag time > > > >> > expired and quickly reacting to tasks waking up would have create > > > >> > problems in your case? > > > >> > > > >> In my experience, the 'reacting to tasks' bit doesn't work very well. > > > > > > > > Humm.. but in this case we won't be 'reacting', we will be > > > > 'anticipating' tasks' needs, right? > > > > > > Are you saying we will start ramping frequency before the next > > > activation so that we're ready for it? > > > > > > > I'm saying that there is no need to ramp, simply select the frequency > > that is needed for a task (or a set of them). > > > > > If not, it sounds like it will only make the frequency request on the > > > next activation when the Active bandwidth increases due to the task > > > waking up. By then task has already started to run, right? > > > > > > > When the task is enqueued back we select the frequency considering its > > bandwidth request (and the bandwidth/utilization of the others). So, > > when it actually starts running it will already have enough capacity to > > finish in time. > > Here we are factoring out the time required to actually switch to the > required OPP. I think Joel was referring to this time. > Right. But, this is an HW limitation. It seems a problem that every scheduler driven decision will have to take into account. So, doesn't make more sense to let the driver (or the governor shim layer) introduce some sort of hysteresis to frequency changes if needed? > That time cannot really be eliminated but from having faster OOP > swiching HW support. Still, jumping strating to the "optimal" OPP > instead of rumping up is a big improvement. > > > -- > #include > > Patrick Bellasi