From patchwork Mon Mar 24 20:05:22 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zoran Markovic X-Patchwork-Id: 26956 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-pa0-f70.google.com (mail-pa0-f70.google.com [209.85.220.70]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id AEDCE20490 for ; Mon, 24 Mar 2014 20:06:30 +0000 (UTC) Received: by mail-pa0-f70.google.com with SMTP id lj1sf15913679pab.1 for ; Mon, 24 Mar 2014 13:06:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:to:cc:subject :date:message-id:in-reply-to:references:sender:precedence:list-id :x-original-sender:x-original-authentication-results:mailing-list :list-post:list-help:list-archive:list-unsubscribe; bh=+WoWiuxMzx5/eskwNmkW2gWTK1sSeR+QGdJmgeOH/hI=; b=KIaGXf2NY6TpaGWiC19EKgc+wQSuewJKnnhma5tWX4rt3jRfjUbSW0LPJ029eFyo5M MzeYx8eOraQWxSGwbfnzVK8UKFXE6ChHuZk/O2elfa7IHbuvPW7BEtDCU8EmPHdE8e3N t4aosK0yWoF3M38J/mZ7/TEpMgFjOQ2NAFVOyZB7PnZbBoPbZcmglTD8CtUD7GMn0Zpc gjP5BVXbUhNWAs95oKPxPBLPhWVKJPq4qIdB+9M49Z24Xl1PSMAk9G2JFxaShdej6dtC +Bn6g+vd5I5EwhdQdNtdhjKlloFl/hOtUNDqRhxzkk2LkvqmlNMLhBmf04f0BQXPiWFE W6dA== X-Gm-Message-State: ALoCoQnn/6udLYkwufJ8mhKvAj4yxrygyanQo2rCqjyew4QX/61+a1QTJouMdgmHSqeNYj8544rV X-Received: by 10.66.222.105 with SMTP id ql9mr30032575pac.9.1395691589982; Mon, 24 Mar 2014 13:06:29 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.80.145 with SMTP id c17ls1911126qgd.60.gmail; Mon, 24 Mar 2014 13:06:29 -0700 (PDT) X-Received: by 10.58.179.115 with SMTP id df19mr72842vec.41.1395691589727; Mon, 24 Mar 2014 13:06:29 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id k20si2753041vcm.205.2014.03.24.13.06.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Mar 2014 13:06:29 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.220.172 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.220.172; Received: by mail-vc0-f172.google.com with SMTP id la4so6449867vcb.3 for ; Mon, 24 Mar 2014 13:06:29 -0700 (PDT) X-Received: by 10.220.192.71 with SMTP id dp7mr67831vcb.45.1395691589607; Mon, 24 Mar 2014 13:06:29 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.220.78.9 with SMTP id i9csp251258vck; Mon, 24 Mar 2014 13:06:29 -0700 (PDT) X-Received: by 10.68.170.66 with SMTP id ak2mr73748211pbc.5.1395691588081; Mon, 24 Mar 2014 13:06:28 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bm8si7780493pab.56.2014.03.24.13.06.27; Mon, 24 Mar 2014 13:06:27 -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; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754160AbaCXUGP (ORCPT + 26 others); Mon, 24 Mar 2014 16:06:15 -0400 Received: from mail-pa0-f41.google.com ([209.85.220.41]:40941 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754063AbaCXUGI (ORCPT ); Mon, 24 Mar 2014 16:06:08 -0400 Received: by mail-pa0-f41.google.com with SMTP id fa1so5936596pad.14 for ; Mon, 24 Mar 2014 13:06:08 -0700 (PDT) X-Received: by 10.66.180.200 with SMTP id dq8mr73872772pac.104.1395691568114; Mon, 24 Mar 2014 13:06:08 -0700 (PDT) Received: from vb-linaro.ric.broadcom.com ([216.31.219.19]) by mx.google.com with ESMTPSA id vf7sm34901832pbc.5.2014.03.24.13.06.06 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Mar 2014 13:06:07 -0700 (PDT) From: Zoran Markovic To: linux-kernel@vger.kernel.org Cc: rob@landley.net, mingo@redhat.com, peterz@infradead.org, rostedt@goodmis.org, daniel.lezcano@linaro.org, zoran.markovic@linaro.org Subject: [RFC PATCH 2/2] sched: Add documentation for idlestat scheduler benchmarking tool Date: Mon, 24 Mar 2014 13:05:22 -0700 Message-Id: <1395691522-3561-3-git-send-email-zoran.markovic@linaro.org> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1395691522-3561-1-git-send-email-zoran.markovic@linaro.org> References: <1395691522-3561-1-git-send-email-zoran.markovic@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: zoran.markovic@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.220.172 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , This patch documents the proposed functionality of idlestat tool and states its intended use for scheduler benchmarking. The documentation file describes the design of the tool, what kernel functionality it relies upon, and what information is contained in the output report. It also contains a simple linear model for estimating CPU power consumption during idlestat run. Idlestat focuses itself on CPU and cluster power states in precise intervals in time. This is of particular use when the benchmarked process is a load synthesis tool: idlestat could focus its acquisition period to a particular sub-period in the load sequence. Output results from idlestat can be applied to a power model in order to estimate the power consumption of CPUs and clusters during the benchmark interval. Initial measurements on ARM Versatile Express TC2 platform show a model error of ~2.6% for the linear power model described in the documentation. Cc: Rob Landley Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Daniel Lezcano Signed-off-by: Zoran Markovic --- Documentation/scheduler/idlestat.txt | 79 ++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 Documentation/scheduler/idlestat.txt diff --git a/Documentation/scheduler/idlestat.txt b/Documentation/scheduler/idlestat.txt new file mode 100644 index 0000000..8e6b695 --- /dev/null +++ b/Documentation/scheduler/idlestat.txt @@ -0,0 +1,79 @@ +This document captures the desired operation of the idlestat tool. + +With the advent of battery-powered Linux devices, it became important to add +a power-aware component to the existing CFS scheduler solution. Future +developments in this field need to be benchmarked using a simple tool that +monitors power parameters during system runs and provides sufficient info for +developers to assess how changes to scheduler code affected CPU power +consumption. The idlestat tool attempts to capture this. + +Idlestat uses kernel's FTRACE function to monitor and capture C-state and +P-state transitions of CPUs over a time interval. It extracts the following +information from trace file: + - Times when CPUs entered and exited a certain C-state + - Times when CPUs entered and exited a certain P-state + - Raised IRQs + +Following a successful run, idlestat calculates and reports the following +information: + - Total, average, minimum and maximum time spent in each C-state, + per-CPU. + - Total, average, minimum and maximum time spent in each P-state, + per-CPU. + - Total, average, minimum and maximum time during which all CPUs in + a cluster were in the same C-state, per-cluster. + - Number of times a certain IRQ caused a CPU to exit idle state, + per-CPU and per-IRQ. + +The tool parses sysfs entries to determine the CPU/cluster topology, as well +as supported C-states and P-states per CPU. It is unaware of CPU/cluster power +consumption in each C-state and P-state, but if these parameters are +externally known, a ballpark estimate of the energy consumed during idlestat +run can be calculated as follows: + +energy = sum_per_cpu(PCi*(TCi-TCCi)) + sum_per_cluster(PCCi*TCCi) + + sum_per_cpu(PPi*TPi) + +where: +PCi - is the power consumption of CPU in Ci power state +TCi - is the total time the CPU has spent in Ci power state +PCCi - is the power consumption of cluster in Ci power state +TCCi - is the total time the cluster has spent in Ci power state +PPi - is the power consumption of CPU in Pi power state +TPi - is the total time the CPU has spent in Pi power state + +Below is an example report of one idlestat run on a dual-core system: +clusterA@state hits total(us) avg(us) min(us) max(us) + C1 10821 5879554.00 543.35 0.00 23163.00 + C2 0 0.00 0.00 0.00 0.00 + C3 78 2929290.00 37555.00 0.00 101441.00 + cpu0@state hits total(us) avg(us) min(us) max(us) + C1 6744 6407808.00 950.15 0.00 23194.00 + C2 3 8819.00 2939.67 549.00 5310.00 + C3 75 2960110.00 39468.13 213.00 101441.00 + 350 1047 204490.00 195.31 0.00 4578.00 + 700 5628 396247.00 70.41 0.00 1465.00 + 920 0 0.00 0.00 0.00 0.00 + cpu0 wakeups name count + irq109 ehci_hcd:usb1 1727 + irq029 twd 4524 + irq069 gp_timer 60 + irq115 mmc0 7 + irq044 DMA 3 + cpu1@state hits total(us) avg(us) min(us) max(us) + C1 6544 6398931.00 977.83 0.00 36255.00 + C2 1 1129.00 1129.00 1129.00 1129.00 + C3 77 2955293.00 38380.43 122.00 101471.00 + 350 1124 212428.00 188.99 0.00 18677.00 + 700 5366 408782.00 76.18 0.00 946.00 + 920 0 0.00 0.00 0.00 0.00 + cpu1 wakeups name count + irq029 twd 4737 + +Idlestat does not perform any processing during the acquisition period. It +sleeps while traces are captured, making sure it is non-intrusive to C- +and P-state transitions. During that time, traces are stored in kernel ring +buffers previously sized by idlestat based on the length of acquisition +period and estimated frequency of trace events. Traces are parsed and +analyzed once the acquisition period is complete. +