Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753177AbbD0QBU (ORCPT ); Mon, 27 Apr 2015 12:01:20 -0400 Received: from mail-ig0-f172.google.com ([209.85.213.172]:35137 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751118AbbD0QBS convert rfc822-to-8bit (ORCPT ); Mon, 27 Apr 2015 12:01:18 -0400 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT To: Peter Zijlstra , "Juri Lelli" From: Michael Turquette In-Reply-To: <20150326104150.GW21418@twins.programming.kicks-ass.net> Cc: "Morten Rasmussen" , "mingo@redhat.com" , "vincent.guittot@linaro.org" , "Dietmar Eggemann" , "yuyang.du@intel.com" , "preeti@linux.vnet.ibm.com" , "nico@linaro.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" References: <1423074685-6336-1-git-send-email-morten.rasmussen@arm.com> <1423074685-6336-34-git-send-email-morten.rasmussen@arm.com> <20150324163503.GZ23123@twins.programming.kicks-ass.net> <5512F7F2.2010705@arm.com> <20150325181413.GT21418@twins.programming.kicks-ass.net> <5513DDA4.10802@arm.com> <20150326104150.GW21418@twins.programming.kicks-ass.net> Message-ID: <20150427160113.16410.10935@quantum> User-Agent: alot/0.3.5 Subject: Re: [RFCv3 PATCH 33/48] sched: Energy-aware wake-up task placement Date: Mon, 27 Apr 2015 09:01:13 -0700 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1892 Lines: 39 Quoting Peter Zijlstra (2015-03-26 03:41:50) > On Thu, Mar 26, 2015 at 10:21:24AM +0000, Juri Lelli wrote: > > - what about other sched classes? I know that this is very premature, > > but I can help but thinking that we'll need to do some sort of > > aggregation of requests, and if we put triggers in very specialized > > points we might lose some of the sched classes separation > > So for deadline we can do P state selection (as you're well aware) based > on the requested utilization. Not sure what to do for fifo/rr though, > they lack much useful information (as always). > > Now if we also look ahead to things like the ACPI CPPC stuff we'll see > that CFS and DL place different requirements on the hints. Where CFS > would like to hint a max perf (the hardware going slower due to the code > consisting of mostly stalls is always fine from a best effort energy > pov), the DL stuff would like to hint a min perf, seeing how it 'needs' > to provide a QoS. > > So we either need to carry this information along in a 'generic' way > between the various classes or put the hinting in every class. > > But yes, food for thought for sure. I am a fan of putting the hints in every class. One idea I've been considering is that each sched class could have a small, simple cpufreq governor that expresses its constraints (max for cfs, min qos for dl) and then the cpufreq core Does The Right Thing. This would be a multi-governor approach, which requires some surgery to cpufreq core code, but I like the modularity and maintainability of it more than having one big super governor that has to satisfy every need. Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/