From patchwork Tue Jul 4 17:34:05 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Bellasi X-Patchwork-Id: 107003 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp1250751qge; Tue, 4 Jul 2017 10:34:25 -0700 (PDT) X-Received: by 10.98.112.137 with SMTP id l131mr16266690pfc.194.1499189665685; Tue, 04 Jul 2017 10:34:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499189665; cv=none; d=google.com; s=arc-20160816; b=doKoNHXt6NasNjKNYsonqFGht3xJ05ClLnwM1Rv89ccsvcs03QfKACktOCgKd0izzy dPlSJgHBVRn5S5/EO90e4lYnNXn4zViiBTRAbkA3lQ76yjHd5q/7RKHfP2lBs7B9GsvF ZkCMOCV9gY57Na+VskzMNPrfg2WnwqQsb+qhqsDnlnob+Wu2uB6ROGQY3tK+lFMsKVym qKIr0meHKCH5f+Ym7hrHgquBa7YluKPNq9AUSN40PU/M4mfpH0ookz+24Adld+pGZDT1 AsWiAzgDjrsEjKZeWlIz4ijjPyFH/ee9g3IZlfj8LE3PsSfjXnN4PaIWoOb1TNm0ebui iCJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=QUJzw2Ai/wQqb1wP/aiwcDI9VS6RcgXChAEsMdin+K4=; b=brZ7zfUM4B/dLNy4y/5N3KZry+u3L2NMxROgqzpTKB5L+yOi9nYUHHpS4i7WRq2dHh YVCrzs7NmUiPvCuPYz6uZi+GuhHP8V0QwJdBOYExSuoQB6XmI65mzxyNlqGnVdIeW97a /VKAi7+v18/G0aEKv6RE3KzOR2728guR4JVrG/egVViPl57gXRS0XJ83ywVHJXulTbuY NS3T2BWJLbQqF8rq0dDqUulejb44cAiY+K+ZqE8WBeESMx+nzDJS44QYMi6rcYsdzOy1 hG68fcQH7MhSr3uRYWSriQLnKxuUlKReugvluDKs/iERwqdIoo2shC5x+qdAef8SMTvn iJog== ARC-Authentication-Results: i=1; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u185si15210252pgd.119.2017.07.04.10.34.25; Tue, 04 Jul 2017 10:34:25 -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 S1752031AbdGDReY (ORCPT + 14 others); Tue, 4 Jul 2017 13:34:24 -0400 Received: from foss.arm.com ([217.140.101.70]:48072 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982AbdGDReX (ORCPT ); Tue, 4 Jul 2017 13:34:23 -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 CC0E5344; Tue, 4 Jul 2017 10:34:22 -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 A82A93F41F; Tue, 4 Jul 2017 10:34:20 -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 0/6] cpufreq: schedutil: fixes for flags updates Date: Tue, 4 Jul 2017 18:34:05 +0100 Message-Id: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.7.4 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Each time a CPU utilisation update is issued by the scheduler a flag, which mainly defines which scheduling class is asking for the update, is used by the frequency selection policy to support the selection of the most appropriate OPP. In the current implementation, CPU flags are overridden each time the scheduler calls schedutil for an update. Such a behavior seems to be sub-optimal, especially on systems where frequency domains span across multiple CPUs. Indeed, assuming CPU1 and CPU2 share the same frequency domain, there can be the following issues: A) Small FAIR task running at MAX OPP. A RT task, which just executed on CPU1, can keep the domain at the max frequency for a prolonged period of time after its completion, even if there are no longer RT tasks running on CPUs of its domain. B) FAIR wakeup reducing the OPP of the current RT task. A FAIR task enqueued in a CPU where a RT task is running overrides the flag configured by the RT task thus potentially causing an unwanted frequency drop. C) RT wakeup not running at max OPP. An RT task waking up on a CPU which has recently updated its OPP can be forced to run at a lower frequency because of the throttling enforced by schedutil, even if there are not OPP transitions currently in progress. .:: Patches organization ======================== This series proposes a set of fixes for the aforementioned issues and it's an update addressing all the main comments collected from the previous posting [1]. Patches have been re-ordered to have the "less controversial" bits at the beginning and also to better match the order of the three main issues described above. These are the relative patches: A) Fix small FAIR task running at MAX OPP: cpufreq: schedutil: ignore the sugov kthread for frequencies selections cpufreq: schedutil: reset sg_cpus's flags at IDLE enter B) FAIR wakeup reducing the OPP of the current RT task. cpufreq: schedutil: ensure max frequency while running RT/DL tasks C) RT wakeup not running at max OPP. sched/rt: fast switch to maximum frequency when RT tasks are scheduled cpufreq: schedutil: relax rate-limiting while running RT/DL tasks cpufreq: schedutil: avoid utilisation update when not necessary .:: Experimental Results ======================== The misbehavior have been verified using a set of simple rt-app based synthetic workloads, running on a ARM's Juno R2 board where the CPUs of the big cluster (CPU1 and CPU2) have been reserved to run the workload tasks in isolation from other system tasks. A detailed description of the experiments executed, and the corresponding collected results, is available [2] online. Short highlights for these experiments are: - Patches in group A reduce energy consumption by ~50% by ensuring that a small task is always running at the minimum OPP even when the sugov's RT kthread is used to change frequencies in the same cluster. - Patches in group B increase from 4% to 98% the chances for a RT task to complete its activations while running at the max OPP. - Patches in group C do not show measurable differences mainly because of the slow OPP switching support available on the JUNO board used for testing. However, a trace inspection shows that the sequence of traced events is much more deterministic and it better matches the expected system behaviors. For example, as soon as a RT task wakeup the scheduler ask for an OPP switch to max frequency. Cheers Patrick .:: References ============== [1] https://lkml.org/lkml/2017/3/2/385 [2] https://gist.github.com/derkling/0cd7210e4fa6f2ec3558073006e5ad70 Patrick Bellasi (6): cpufreq: schedutil: ignore sugov kthreads cpufreq: schedutil: reset sg_cpus's flags at IDLE enter cpufreq: schedutil: ensure max frequency while running RT/DL tasks cpufreq: schedutil: update CFS util only if used sched/rt: fast switch to maximum frequency when RT tasks are scheduled cpufreq: schedutil: relax rate-limiting while running RT/DL tasks include/linux/sched/cpufreq.h | 1 + kernel/sched/cpufreq_schedutil.c | 61 ++++++++++++++++++++++++++++++++-------- kernel/sched/idle_task.c | 4 +++ kernel/sched/rt.c | 15 ++++++++-- 4 files changed, 67 insertions(+), 14 deletions(-) -- 2.7.4