From patchwork Fri Mar 16 11:25:37 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vincent Guittot X-Patchwork-Id: 131917 Delivered-To: patch@linaro.org Received: by 10.46.84.17 with SMTP id i17csp617409ljb; Fri, 16 Mar 2018 04:25:55 -0700 (PDT) X-Google-Smtp-Source: AG47ELuatHLXSJq8K0RjTMdwcFbi23lCseFht0jtKQE+yZEQ0f32zY3C2+Pm12/Cd2p0tLCpUzM5 X-Received: by 10.101.100.9 with SMTP id a9mr1184765pgv.209.1521199555494; Fri, 16 Mar 2018 04:25:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521199555; cv=none; d=google.com; s=arc-20160816; b=sZv6VVZkFFGny4E0l0FfnrvSUUMSoCtRn3OYSGHaegY/VbsOwXNdj5awKSkrkxefP9 uNGzO0ONCqlV2maE8plunIk8/47Chrxnl3PBU/LhRpNhM2W+a+PvzjBRCnNRR23xxwQ+ N9Cr2IEFtgpIpb8PY9udBlIs4oXGRaFQqUtG9mfHSa+MdYofZvNaHgcRr9OM/P64FhLm /l6Tfc6OdRuilG+8M69Ev5tNnAlXe7SJL/CG85HLVMk50K+mcn3m+5ouuUHjuH6aaUSP oDEDoFq4ZdEduwfujLiSDFLfF/zJ3y+TarV6pcEp3eVg5yuPidZL5bFTJ5V8DdddIWG0 Bd7Q== 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 :dkim-signature:arc-authentication-results; bh=u/Rhz5Rcln49Lc8F18wc47A+oJAurmoXtplgMIkLZpM=; b=Go7fwd03hQxbgIW8BUKWSbHZZxniRFX0IHyIBUhocVLeMur+jZ/xaB4faRiNxCS/uT /1C4tMFmTv09tBzJzVXFMx7tkj6ygzAbQYRC179RRUvVAP0r1dhcR6DUeGRDlAHmpk4u xY3NRd9GsaMYmZNjXkAiRMAb+vk4iFFWMvT+s4WJQmtGZ0io6UmPU6NTQr++/UiYEu4A 9OFSa9y7Zy2wGotKtU2WHU7hJ4xWFDSIFd0PV2wIF88Z6Kpv3dthuGtICA1OYtJVLQWx YpUQKLJHy05n7Gg4KmPVf1Yw40OOGSNOQMxje0GQ0DN8OCpcUKtIBzLCGOLdAriY5KE/ Cl1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hCWG6Yio; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 60-v6si5986355plc.66.2018.03.16.04.25.55; Fri, 16 Mar 2018 04:25:55 -0700 (PDT) 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; dkim=pass header.i=@linaro.org header.s=google header.b=hCWG6Yio; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753882AbeCPLZw (ORCPT + 28 others); Fri, 16 Mar 2018 07:25:52 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36805 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753678AbeCPLZv (ORCPT ); Fri, 16 Mar 2018 07:25:51 -0400 Received: by mail-wm0-f68.google.com with SMTP id n3so2404294wmd.1 for ; Fri, 16 Mar 2018 04:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=u/Rhz5Rcln49Lc8F18wc47A+oJAurmoXtplgMIkLZpM=; b=hCWG6Yio7l3wTYzkjeyMCc1hpQZveksCuWMIrwXcRFCo88Q5/KVnojjgPSGwfQYcSV h5vMBNoNzbnPYdqTahOuXBe5KK7A8tslQcZV7Vn7aE09rxu06yo9kejXAw1BpoeFPAdh G0VboiLsjiPj78MkG6IlLtKdpGasGWD8RONBQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=u/Rhz5Rcln49Lc8F18wc47A+oJAurmoXtplgMIkLZpM=; b=QTuvbw8YKyCBVx1dlrDgfLDAlPMm8gfXi3NU5p3xqWM1MmH+eD5yXYy00lf3pbErei QmOCXiiAIPj08OX2OtTxpw9UXZFl997RLL4eprGmaWryEXNmo4IpScVO49mfkYgL2v41 nA3R49DyvZV+/GsttxTzzTFmTqHZaCVj6Rs16+tcWRlFJEKAFAZWgxvV3ktn81xpDU64 izZXLRY41b5ULFjpkqiZFXwl/EyBtr0+PPyL/czVOS8wxkRAUNsc0+fwCmrZlIH5sZcV slJT7V1KW/ssJomXNXU+xyqD+SKkt9jfDrIyPkf6BYJv7+pc0y5iCoZhcgzDkCa9G1oK 5tbw== X-Gm-Message-State: AElRT7FrJEc6ZbSg4ICPx2almyzzxW6TwDsAp1uHYtWMFxDiC/Y2zocv SEmr2S62xEXIXO0ZiDv3oEIOzg== X-Received: by 10.28.6.205 with SMTP id 196mr1610832wmg.136.1521199549810; Fri, 16 Mar 2018 04:25:49 -0700 (PDT) Received: from localhost.localdomain ([2a01:e0a:f:6020:9471:2e09:99e5:f59]) by smtp.gmail.com with ESMTPSA id m15sm6785292wrb.58.2018.03.16.04.25.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Mar 2018 04:25:47 -0700 (PDT) From: Vincent Guittot To: peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org, rjw@rjwysocki.net Cc: juri.lelli@redhat.com, dietmar.eggemann@arm.com, Morten.Rasmussen@arm.com, viresh.kumar@linaro.org, valentin.schneider@arm.com, Vincent Guittot Subject: [PATCH 0/4 v4] sched/rt: track rt rq utilization Date: Fri, 16 Mar 2018 12:25:37 +0100 Message-Id: <1521199541-15308-1-git-send-email-vincent.guittot@linaro.org> 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 When both cfs and rt tasks compete to run on a CPU, we can see some frequency drops with schedutil governor. In such case, the cfs_rq's utilization doesn't reflect anymore the utilization of cfs tasks but only the remaining part that is not used by rt tasks. We should monitor the stolen utilization and take it into account when selecting OPP. This patchset doesn't change the OPP selection policy for RT tasks but only for CFS tasks A rt-app use case which creates an always running cfs thread and a rt threads that wakes up periodically with both threads pinned on same CPU, show lot of frequency switches of the CPU whereas the CPU never goes idles during the test. I can share the json file that I used for the test if someone is interested in. For a 15 seconds long test on a hikey 6220 (octo core cortex A53 platfrom), the cpufreq statistics outputs (stats are reset just before the test) : $ cat /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans without patchset : 1230 with patchset : 14 If we replace the cfs thread of rt-app by a sysbench cpu test, we can see performance improvements: - Without patchset : Test execution summary: total time: 15.0009s total number of events: 4903 total time taken by event execution: 14.9972 per-request statistics: min: 1.23ms avg: 3.06ms max: 13.16ms approx. 95 percentile: 12.73ms Threads fairness: events (avg/stddev): 4903.0000/0.00 execution time (avg/stddev): 14.9972/0.00 - With patchset: Test execution summary: total time: 15.0014s total number of events: 7694 total time taken by event execution: 14.9979 per-request statistics: min: 1.23ms avg: 1.95ms max: 10.49ms approx. 95 percentile: 10.39ms Threads fairness: events (avg/stddev): 7694.0000/0.00 execution time (avg/stddev): 14.9979/0.00 The performance improvement is 56% for this use case. Patch 1 move pelt code in pelt.c file Patch 2 tracks utilization of rt_rq. Patch 3 adds the rt_rq's utilization when selection OPP for cfs tasks Patch 4 support periodic update of blocked rt utilization Change since v3: - add support of periodic update of blocked utilization - rebase on lastest tip/sched/core Change since v2: - move pelt code into a dedicated pelt.c file - rebase on load tracking changes Change since v1: - Only a rebase. I have addressed the comments on previous version in patch 1/2 Vincent Guittot (4): sched/pelt: Move pelt related code in a dedicated file sched/rt: add rt_rq utilization tracking cpufreq/schedutil: add rt utilization tracking sched/nohz: monitor rt utilization kernel/sched/Makefile | 2 +- kernel/sched/cpufreq_schedutil.c | 4 +- kernel/sched/fair.c | 321 ++----------------------------------- kernel/sched/pelt.c | 331 +++++++++++++++++++++++++++++++++++++++ kernel/sched/pelt.h | 24 +++ kernel/sched/rt.c | 8 + kernel/sched/sched.h | 28 ++++ 7 files changed, 410 insertions(+), 308 deletions(-) create mode 100644 kernel/sched/pelt.c create mode 100644 kernel/sched/pelt.h -- 2.7.4