Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752139AbdGFP5W (ORCPT ); Thu, 6 Jul 2017 11:57:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:35182 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750970AbdGFP5T (ORCPT ); Thu, 6 Jul 2017 11:57:19 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12F5022B54 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Thu, 6 Jul 2017 11:57:15 -0400 From: Steven Rostedt To: Juri Lelli Cc: peterz@infradead.org, mingo@redhat.com, rjw@rjwysocki.net, viresh.kumar@linaro.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, tglx@linutronix.de, vincent.guittot@linaro.org, luca.abeni@santannapisa.it, claudio@evidence.eu.com, tommaso.cucinotta@santannapisa.it, bristot@redhat.com, mathieu.poirier@linaro.org, tkjos@android.com, joelaf@google.com, andresoportus@google.com, morten.rasmussen@arm.com, dietmar.eggemann@arm.com, patrick.bellasi@arm.com Subject: Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Message-ID: <20170706115715.6154d823@gandalf.local.home> In-Reply-To: <20170705085905.6558-1-juri.lelli@arm.com> References: <20170705085905.6558-1-juri.lelli@arm.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 506 Lines: 18 On Wed, 5 Jul 2017 09:58:57 +0100 Juri Lelli wrote: > Hi, > > v1 of the RFC set implementing frequency/cpu invariance and OPP selection for It would be nice if you specify what "OPP" stands for. A quick google search shows "Other Peoples Privates", which isn't the type of selection I would be looking for. -- Steve > SCHED_DEADLINE [1]. The set is based on tip/sched/core as of today > (72298e5c92c5), which now already includes Luca's "CPU reclaiming for > SCHED_DEADLINE". >