From patchwork Thu Mar 2 15:45:01 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Bellasi X-Patchwork-Id: 94790 Delivered-To: patch@linaro.org Received: by 10.182.3.34 with SMTP id 2csp346581obz; Thu, 2 Mar 2017 07:49:44 -0800 (PST) X-Received: by 10.84.224.197 with SMTP id k5mr19812297pln.15.1488469784600; Thu, 02 Mar 2017 07:49:44 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s3si7754117plb.249.2017.03.02.07.49.44; Thu, 02 Mar 2017 07:49:44 -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 S1754660AbdCBPt1 (ORCPT + 25 others); Thu, 2 Mar 2017 10:49:27 -0500 Received: from foss.arm.com ([217.140.101.70]:32846 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752728AbdCBPqi (ORCPT ); Thu, 2 Mar 2017 10:46:38 -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 DE76CC28; Thu, 2 Mar 2017 07:45:23 -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 EE5403F220; Thu, 2 Mar 2017 07:45:20 -0800 (PST) From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" Cc: Patrick Bellasi , Viresh Kumar , Steven Rostedt , Vincent Guittot , John Stultz , Juri Lelli , Todd Kjos , Tim Murray , Andres Oportus , Joel Fernandes , Morten Rasmussen , Dietmar Eggemann , Chris Redpath Subject: [PATCH 0/6] cpufreq: schedutil: fixes for flags updates Date: Thu, 2 Mar 2017 15:45:01 +0000 Message-Id: <1488469507-32463-1-git-send-email-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The current version of schedutil has some issues related to the management of update flags used by systems with frequency domains spawning multiple CPUs. Each time a CPU utilisation update is issued by the scheduler a set of flags are configured to define (mainly) which class is asking for a utilisation update. These flags are then used by the frequency selection policy to identify the OPP to choose. In the current implementation, CPU flags are overridden each time the scheduler calls schedutil for an update. Such a behaviour produces issues in these scenarios, where we assume CPU1 and CPU2 share the same frequency domain: a) a RT task which executed on CPU1 can keep the domain at an high frequency for a long period of time, even if there are no longer RT tasks on CPUs in that domain b) a FAIR task co-scheduled in the same CPU of a RT task can override the flags configured by the RT task and potentially this can cause an unwanted frequency drop These misbehaviours have been verified using a set of simple rt-app based synthetic workloads, running on a ARM's Juno board, and results are available in this Notebook [1]. This series proposes a set of fixes for the aforementioned issues as well as a small improvement to speedup the selection of the maximum frequency when RT tasks enter a CPU. This series is based on top of today's tip/sched/core and is public available from this repository: git://www.linux-arm.com/linux-pb eas/schedutil/flags_fixes Cheers Patrick [1] https://gist.github.com/d6a21b459a18091b2b058668a550010d Patrick Bellasi (6): cpufreq: schedutil: reset sg_cpus's flags at IDLE enter cpufreq: schedutil: ignore the sugov kthread for frequencies selections cpufreq: schedutil: ensure max frequency while running RT/DL tasks cpufreq: schedutil: relax rate-limiting while running RT/DL tasks cpufreq: schedutil: avoid utilisation update when not necessary sched/rt: fast switch to maximum frequency when RT tasks are scheduled include/linux/sched.h | 1 + kernel/sched/cpufreq_schedutil.c | 59 ++++++++++++++++++++++++++++++++++------ kernel/sched/idle_task.c | 4 +++ kernel/sched/rt.c | 15 ++++++++-- 4 files changed, 68 insertions(+), 11 deletions(-) -- 2.7.4