Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3919950pxb; Tue, 10 Nov 2020 03:38:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJzIEcj7phj//BfRn0iaorJz0nf9n1p+afC2fbC6QPLBWD5tY5w7naWKNb/TmogYY6uJ+evM X-Received: by 2002:a17:906:158e:: with SMTP id k14mr19058787ejd.496.1605008294549; Tue, 10 Nov 2020 03:38:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605008294; cv=none; d=google.com; s=arc-20160816; b=vdfcZfciWaivuofIi7IxLMKPBuss//bpMikMrI/0sfTbkDC6N35nuh+uvJQRB+PTE1 Xb11vyPPruLN62EnzdcCQDkNaxUMLadjrf28U9+h0qSlbCIw853GdHGzkvV/hAKL2cmu Cutb2m5ipd7zdWBJRcqHGVh2VpS4q2QeLAYf5g7g4XGKjaVR1IZw9/rBYBnawnx7J8ED 0w5dwNcko+y94wBzp+guK/SrICAVastaIh6hHbEWsGPCxW3E3SZT6GmgOCYtmyvc0sa2 HPDin4HlInRofqomHgBdjQ8ypITTCrLjjPdYDm0vCw67f05f94DWRPARkt0j1yY0g6+j pwKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=g3wpHe46uF++TwrzhmvsZlcdZS8+u4opSEKV2MCS2dw=; b=ePO3ajoDXYGuofYEkzAKYOwkt2A8H7STBOHPhRfKBIFYD1VJ/kmPP3CBHxyzZoRL71 6yR8dW0nEKcpJRb8R1U31auCfo7s79vc+b/9HGivUfdQHt3jT1YMXqtRoQJMjKiZxZNV 3RcjaQ+S/HL6WTwLzQ4SffJx/Ml2sZkVZKjif6mGiEGw6aajbuSKwTpUY7oivQXHgBMz hK9Gzh+/17Cbcnd7VJtVNjETQovmyfYW8Z9rPWV3mINjOsZ7zSQWGijIXT+UhIxq7s/Q 7p7mjdsNa0iIEVC0TRBMl+b5ooUb9dWIKt7V2M5Ao8O7c2iw9rZiQWO4p3HBTwb+VnXZ z78A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o9si9346013edi.568.2020.11.10.03.37.51; Tue, 10 Nov 2020 03:38:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729909AbgKJLgU (ORCPT + 99 others); Tue, 10 Nov 2020 06:36:20 -0500 Received: from foss.arm.com ([217.140.110.172]:54418 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726152AbgKJLgS (ORCPT ); Tue, 10 Nov 2020 06:36:18 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CA8721396; Tue, 10 Nov 2020 03:36:17 -0800 (PST) Received: from [10.57.21.178] (unknown [10.57.21.178]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 990B03F6CF; Tue, 10 Nov 2020 03:36:15 -0800 (PST) Subject: Re: [PATCH] cpufreq: stats: Switch to ktime and msec instead of jiffies and usertime To: Viresh Kumar Cc: Rafael Wysocki , Jonathan Corbet , linux-pm@vger.kernel.org, Vincent Guittot , Thomas Renninger , Shuah Khan , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org References: <0e0fb542b6f6b26944cb2cf356041348aeac95f6.1605006378.git.viresh.kumar@linaro.org> From: Lukasz Luba Message-ID: <5860b346-4eab-4018-87e4-a6313115fa2d@arm.com> Date: Tue, 10 Nov 2020 11:36:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <0e0fb542b6f6b26944cb2cf356041348aeac95f6.1605006378.git.viresh.kumar@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/10/20 11:07 AM, Viresh Kumar wrote: > The cpufreq and thermal core, both provide sysfs statistics to help > userspace learn about the behavior of frequencies and cooling states. > > This is how they look: > > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:208000 11 > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:432000 147 > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:729000 1600 > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:960000 879 > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:1200000 399 > > /sys/class/thermal/cooling_device0/stats/time_in_state_ms:state0 4097 > /sys/class/thermal/cooling_device0/stats/time_in_state_ms:state1 8932 > /sys/class/thermal/cooling_device0/stats/time_in_state_ms:state2 15868 > /sys/class/thermal/cooling_device0/stats/time_in_state_ms:state3 1384 > /sys/class/thermal/cooling_device0/stats/time_in_state_ms:state4 103 > > Here, state0 of thermal corresponds to the highest frequency of the CPU, > i.e. 1200000 and state4 to the lowest one. > > While both of these try to show similar kind of data (which can still be > very much different from each other), the values looked different (by a > factor of 10, i.e. thermal's time_in_state is almost 10 times that of > cpufreq time_in_state). > > This comes from the fact that cpufreq core displays the time in usertime > units (10 ms). > > It would be better if both the frameworks displayed times in the same > unit as the users may need to correlate between them and different > scales just make it awkward. And the choice of thermal core for that > (msec) seems to be a better choice as it is easier to read. > > The thermal core also does the stats calculations using ktime, which is > much more accurate as compared to jiffies used by cpufreq core. > > This patch updates the cpufreq core to use ktime for the internal > calculations and changes the units of time_in_state to msec. > > The results look like this after this commit: > > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:208000 13 > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:432000 790 > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:729000 12492 > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:960000 13259 > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:1200000 3830 > > /sys/class/thermal/cooling_device0/stats/time_in_state_ms:state0 3888 > /sys/class/thermal/cooling_device0/stats/time_in_state_ms:state1 13432 > /sys/class/thermal/cooling_device0/stats/time_in_state_ms:state2 12336 > /sys/class/thermal/cooling_device0/stats/time_in_state_ms:state3 740 > /sys/class/thermal/cooling_device0/stats/time_in_state_ms:state4 0 > > FWIW, tools/power/cpupower/ does consume the time_in_state values from > the sysfs files but it is independent of the unit of the time and didn't > require an update. > > Signed-off-by: Viresh Kumar > --- > Documentation/cpu-freq/cpufreq-stats.rst | 5 +-- > drivers/cpufreq/cpufreq_stats.c | 47 +++++++++++++----------- > 2 files changed, 28 insertions(+), 24 deletions(-) > > diff --git a/Documentation/cpu-freq/cpufreq-stats.rst b/Documentation/cpu-freq/cpufreq-stats.rst > index 9ad695b1c7db..9f94012a882f 100644 > --- a/Documentation/cpu-freq/cpufreq-stats.rst > +++ b/Documentation/cpu-freq/cpufreq-stats.rst > @@ -64,9 +64,8 @@ need for a reboot. > > This gives the amount of time spent in each of the frequencies supported by > this CPU. The cat output will have "