From patchwork Fri Mar 24 14:08:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Juri Lelli X-Patchwork-Id: 95949 Delivered-To: patch@linaro.org Received: by 10.140.89.233 with SMTP id v96csp64038qgd; Fri, 24 Mar 2017 07:09:20 -0700 (PDT) X-Received: by 10.84.139.195 with SMTP id 61mr11118419plr.109.1490364559959; Fri, 24 Mar 2017 07:09:19 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t2si2140056pfl.148.2017.03.24.07.09.19; Fri, 24 Mar 2017 07:09:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756563AbdCXOJT (ORCPT + 13 others); Fri, 24 Mar 2017 10:09:19 -0400 Received: from foss.arm.com ([217.140.101.70]:41164 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752352AbdCXOJS (ORCPT ); Fri, 24 Mar 2017 10:09:18 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1F94F2B; Fri, 24 Mar 2017 07:09:17 -0700 (PDT) Received: from e106622-lin.cambridge.arm.com (e106622-lin.cambridge.arm.com [10.1.211.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id CCE6C3F575; Fri, 24 Mar 2017 07:09:13 -0700 (PDT) From: Juri Lelli To: peterz@infradead.org, mingo@redhat.com, rjw@rjwysocki.net, viresh.kumar@linaro.org Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, tglx@linutronix.de, vincent.guittot@linaro.org, rostedt@goodmis.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, juri.lelli@arm.com Subject: [RFD PATCH 0/5] SCHED_DEADLINE freq/cpu invariance and OPP selection Date: Fri, 24 Mar 2017 14:08:55 +0000 Message-Id: <20170324140900.7334-1-juri.lelli@arm.com> X-Mailer: git-send-email 2.10.0 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Hi, this is a very exploratory set implementing frequency/cpu invariance and OPP selection for SCHED_DEADLINE. The set has been slightly tested on a Juno platform. While the actual implementation is very premature, I'm posting this early to facilitate discussion at OSPM-summit [1]. Results of the testing, highlighting why these features are useful are available here: - without the set https://gist.github.com/a6e3ee99cec32e00cc537b53cd3d54d2 - with the set https://gist.github.com/1f7d485fc3ce9234fe627dcb53b2935c The set is based on tip/sched/core as of today (bc4278987e38) plus a couple of schedutil fixes coming from linux-pm/linux-next and Luca's "CPU reclaiming for SCHED_DEADLINE" v5 [2]. Patches high level description: o [01-02]/05 add the necessary links to start accounting DEADLINE contribution to OPP selection o 03/05 it's an hack to make possible (on ARM) to change frequency for DEADLINE tasks (that would possibly delay the SCHED_FIFO worker kthread); suggestions on how to do this properly are very welcome o 04/05 it's a schedutil change that copes with the fact that DEADLINE doesn't require periodic OPP selection triggering point o 05/05 implements frequency/cpu invariance for tasks' reservation parameters*; which basically means that we implement GRUB-PA [3] Please have a look. Feedback on how we want to shape this is the sole purpose of this posting. In case you would like to test this out: git://linux-arm.org/linux-jl.git upstream/deadline/freq-rfd Best, - Juri [1] http://retis.sssup.it/ospm-summit/index.html [2] https://marc.info/?l=linux-kernel&m=149029880524038 [3] C. Scordino, G. Lipari, A Resource Reservation Algorithm for Power-Aware Scheduling of Periodic and Aperiodic Real-Time Tasks, IEEE Transactions on Computers, December 2006. * Notice that this currently breaks !CONFIG_SMP, as arch_scale_{freq,cpu} _capacity and SCHED_CAPACITY_SCALE are only defined on CONFIG_SMP. Fixing this particular issue is straightforward, but we should probably look into making frequency scaling (and PELT averages) available on !CONFIG_SMP as well (so that schedutil can work on such configurations for example). Since this is only an RFD and since a proper rework might be non trivial, I decided to leave it out of scope for the time being. Juri Lelli (5): sched/cpufreq_schedutil: make use of DEADLINE utilization signal sched/deadline: move cpu frequency selection triggering points sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE sched/cpufreq_schedutil: always consider all CPUs when deciding next freq sched/deadline: make bandwidth enforcement scale-invariant include/linux/sched.h | 1 + include/linux/sched/cpufreq.h | 2 -- include/uapi/linux/sched.h | 1 + kernel/sched/core.c | 19 +++++++++++++++++-- kernel/sched/cpufreq_schedutil.c | 37 ++++++++++++++++++++++--------------- kernel/sched/deadline.c | 40 +++++++++++++++++++++++++++++++++------- kernel/sched/fair.c | 2 -- kernel/sched/sched.h | 10 +++++++++- 8 files changed, 83 insertions(+), 29 deletions(-) -- 2.10.0