From patchwork Thu Nov 30 11:47:21 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Bellasi X-Patchwork-Id: 120146 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp558905qgn; Thu, 30 Nov 2017 03:48:07 -0800 (PST) X-Google-Smtp-Source: AGs4zMb9sW5JgiOnWqiotdYCbii/WKOuS4DiIphfcmMbH6byjzzyKGb8UQDNUTzg6S0VSdYm1c3S X-Received: by 10.101.98.131 with SMTP id f3mr2109011pgv.366.1512042487219; Thu, 30 Nov 2017 03:48:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512042487; cv=none; d=google.com; s=arc-20160816; b=spCO6cj9Z0GlR1T67KYbPM/wlCrVqQw6ghTod0AsgPeIPLmoQkZzCduPIV4/C7NAe+ eYh33HjyVnPjlXBSqzw+7mnwi4p1MJsWv/9aLFVdhWpCnoGmYtYsaN4Wa2ZaxdIDd4ou pzkOQ+mMbG3sgxz792eZDZUd3i+W2KhT/u7AGJvxKgq7w4iOxXFuNiCOQlxhL4X6DwhW w8M4JpOAI9DgOlFgwJU258RUAosPNSJYc/zg/jR/J1n0FyK/ZH46qrUWwwDizBVVLoTP Nrqjc2EM+FZXxCpqM2fDLXpapOKKcuBn3v0bPjXchnxkEO8QNU2pieG4edeCMZHfGALt nYCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=UcuvBk3Agozojw9x1RDUVG5jZ73tvgsKTGWzlC7gSUk=; b=avr2/+v5vzn5jCWuGErKFedxYICj7NR1Syj8tYlXb0Vy5jG2EUFfDJJG7V1LK7YY0L EAy+wshaK6kdqQIZpKXMbGDcZbsKzcEpoZvJelvCF09RK8l6hnlUwfr5flE6dAiwFLUa Z2sU268WKvFGDHoJIK0kaB1Vnkghi0E9LmwUa+Vll2bK2LyZkZGvXEVDSdMjQjN3hn90 +D69+ofIXyGhVsxj5nqNCoLLm+7IQMHz8qyilNrukWKc9Sm8qh3PHeYZdUqVjvt5RE/P zg/bE8nDJ3FZhxOP7Bs/Runp1/5Hm1M9POmsacgYmLTClF0SZUXejgOeStOFyNVMR07U KuiA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w11si3130892pfk.209.2017.11.30.03.48.06; Thu, 30 Nov 2017 03:48:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752676AbdK3LsD (ORCPT + 26 others); Thu, 30 Nov 2017 06:48:03 -0500 Received: from foss.arm.com ([217.140.101.70]:51310 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752550AbdK3LsA (ORCPT ); Thu, 30 Nov 2017 06:48:00 -0500 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 B0B2A1610; Thu, 30 Nov 2017 03:47:59 -0800 (PST) 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 7A4C43F236; Thu, 30 Nov 2017 03:47:57 -0800 (PST) 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 , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes Subject: [PATCH v3 4/6] sched/rt: fast switch to maximum frequency when RT tasks are scheduled Date: Thu, 30 Nov 2017 11:47:21 +0000 Message-Id: <20171130114723.29210-5-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.14.1 In-Reply-To: <20171130114723.29210-1-patrick.bellasi@arm.com> References: <20171130114723.29210-1-patrick.bellasi@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wakes up 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 Reviewed-by: Dietmar Eggemann 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 --- Changes from v2: - rebased on v4.15-rc1 - use cpufreq_update_util() instead of cpufreq_update_this_cpu() Change-Id: I3794615819270fe175cb118eef3f7edd61f602ba --- kernel/sched/rt.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) -- 2.14.1 diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 4056c19ca3f0..6984032598a6 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -959,9 +959,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_util(rq, SCHED_CPUFREQ_RT); - schedstat_set(curr->se.statistics.exec_max, max(curr->se.statistics.exec_max, delta_exec)); @@ -1327,6 +1324,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_util(rq, SCHED_CPUFREQ_RT); } static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags) @@ -1564,6 +1564,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_util(rq, SCHED_CPUFREQ_RT); + /* The running task is never eligible for pushing */ dequeue_pushable_task(rq, p); @@ -2282,6 +2285,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_util(rq, SCHED_CPUFREQ_RT); + update_curr_rt(rq); watchdog(rq, p); @@ -2317,6 +2323,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_util(rq, SCHED_CPUFREQ_RT); + /* The running task is never eligible for pushing */ dequeue_pushable_task(rq, p); }