From patchwork Tue Jul 4 17:34:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Bellasi X-Patchwork-Id: 9825463 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 8A53860237 for ; Tue, 4 Jul 2017 17:35:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 770C826E5D for ; Tue, 4 Jul 2017 17:35:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6ADC1284C8; Tue, 4 Jul 2017 17:35:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6591D26E5D for ; Tue, 4 Jul 2017 17:35:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752454AbdGDRe5 (ORCPT ); Tue, 4 Jul 2017 13:34:57 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:48168 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752452AbdGDRez (ORCPT ); Tue, 4 Jul 2017 13:34:55 -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 DE1D6165C; Tue, 4 Jul 2017 10:34:34 -0700 (PDT) Received: from e110439-lin.cambridge.arm.com (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id B9BF93F41F; Tue, 4 Jul 2017 10:34:32 -0700 (PDT) From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Juri Lelli , Joel Fernandes , Andres Oportus , Todd Kjos , Morten Rasmussen , Dietmar Eggemann Subject: [PATCH v2 5/6] sched/rt: fast switch to maximum frequency when RT tasks are scheduled Date: Tue, 4 Jul 2017 18:34:10 +0100 Message-Id: <1499189651-18797-6-git-send-email-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> References: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Currently schedutil updates are triggered for the RT class using a single call place, which is part of the rt::update_curr_rt() used in: - dequeue_task_rt: but it does not make sense to set the schedutil's SCHED_CPUFREQ_RT in case the next task should not be an RT one - put_prev_task_rt: likewise, we set the SCHED_CPUFREQ_RT flag without knowing if required by the next task - pick_next_task_rt: likewise, the schedutil's SCHED_CPUFREQ_RT is set in case the prev task was RT, while we don't yet know if the next will be RT - task_tick_rt: that's the only really useful call, which can ramp up the frequency in case a RT task started its execution without a chance to order a frequency switch (e.g. because of the schedutil ratelimit) Apart from the last call in task_tick_rt, the others are at least useless. Thus, although being a simple solution, not all the call sites of that update_curr_rt() are interesting to trigger a frequency switch as well as some of the most interesting points are not covered by that call. For example, a task set to RT has to wait the next tick to get the frequency boost. This patch fixes these issues by placing explicitly the schedutils update calls in the only sensible places, which are: - when an RT task wakeups and it's enqueued in a CPU - when we actually pick a RT task for execution - at each tick time - when a task is set to be RT Signed-off-by: Patrick Bellasi Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org --- kernel/sched/rt.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 45caf93..8c25e95 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -969,9 +969,6 @@ static void update_curr_rt(struct rq *rq) if (unlikely((s64)delta_exec <= 0)) return; - /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ - cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT); - schedstat_set(curr->se.statistics.exec_max, max(curr->se.statistics.exec_max, delta_exec)); @@ -1337,6 +1334,9 @@ enqueue_task_rt(struct rq *rq, struct task_struct *p, int flags) if (!task_current(rq, p) && p->nr_cpus_allowed > 1) enqueue_pushable_task(rq, p); + + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT); } static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags) @@ -1574,6 +1574,9 @@ pick_next_task_rt(struct rq *rq, struct task_struct *prev, struct rq_flags *rf) p = _pick_next_task_rt(rq); + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT); + /* The running task is never eligible for pushing */ dequeue_pushable_task(rq, p); @@ -2367,6 +2370,9 @@ static void task_tick_rt(struct rq *rq, struct task_struct *p, int queued) { struct sched_rt_entity *rt_se = &p->rt; + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT); + update_curr_rt(rq); watchdog(rq, p); @@ -2402,6 +2408,9 @@ static void set_curr_task_rt(struct rq *rq) p->se.exec_start = rq_clock_task(rq); + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT); + /* The running task is never eligible for pushing */ dequeue_pushable_task(rq, p); }