From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754811AbdLTItI (ORCPT ); Wed, 20 Dec 2017 03:49:08 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:37218 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754774AbdLTItC (ORCPT ); Wed, 20 Dec 2017 03:49:02 -0500 X-Google-Smtp-Source: ACJfBosSb5Rv1AM5UShcO7QrlbPeXfHNW2nAyeGNZ6B754b06fdJinNyDrsZwfxTUkvM/5dxTR2Bjg== Date: Wed, 20 Dec 2017 14:18:59 +0530 From: Viresh Kumar To: Peter Zijlstra Cc: Rafael Wysocki , Ingo Molnar , linux-pm@vger.kernel.org, Vincent Guittot , dietmar.eggemann@arm.com, morten.rasmussen@arm.com, juri.lelli@redhat.com, tkjos@android.com, joelaf@google.com, linux-kernel@vger.kernel.org, patrick.bellasi@arm.com Subject: Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags Message-ID: <20171220084859.GY19815@vireshk-i7> References: <17ff0b5d83a1275a98f0d1b87daf275f3e964af3.1513158452.git.viresh.kumar@linaro.org> <20171219192504.nstxsfii6y7rh37w@hirez.programming.kicks-ass.net> <20171220040446.GS19815@vireshk-i7> <20171220083115.n4mc4pdkvycakce2@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171220083115.n4mc4pdkvycakce2@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 20-12-17, 09:31, Peter Zijlstra wrote: > On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote: > Please use the normal link format: > > https://lkml.kernel.org/r/$MSGID > > Then I can find them without having to resort to a frigging browser > thing. Sure, and that would be much easier for me as well as that's how I got to those links. Here they are again .. https://lkml.kernel.org/r/20171130114723.29210-2-patrick.bellasi@arm.com https://lkml.kernel.org/r/20171130114723.29210-3-patrick.bellasi@arm.com https://lkml.kernel.org/r/20171130114723.29210-7-patrick.bellasi@arm.com > I'll try and dig through the email I have. Thanks. > > Well that also looks fine to me, and that would mean this: > > > > - We remove SCHED_CPUFREQ_RT and SCHED_CPUFREQ_DL flags, but still > > call the utilization callbacks from RT and DL classes. > > Didn't juri have patches to make DL do something sane? But yes, I think > those flags are part of the problem. Sure, DL will be more like CFS going forward. I was just commenting based on what we have upstream today. > > - From the utilization handler, we check runqueues of all three sched > > classes to see if they have some work pending (this can be done > > smartly by checking only RT first and skipping other checks if RT > > has some work). > > No that's wrong. DL should provide a minimum required based on existing > reservations, we can add the expected CFS average on top and request > that. Right, that should be the case after Juri's patches. > And for RT all we need to know is if current is of that class, otherwise > we don't care. What about this case: A CFS task is running currently and an RT task is enqueued. - Is it always the case that the CFS task is preempted immediately and the CPU is given to RT task ? I was talking to Vincent earlier and he told me that for certain configurations the CFS task may keep running until the next tick. - What if the CFS task has disabled preemption ? - More corner cases like this ? Above cases may not let schedutil to raise frequency to MAX even when we have RT stuff enqueued. And that's why I tried to track all sched classes for which we have work enqueued for. There are great chances that my understanding here is wrong though :) -- viresh