Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp174294pxb; Wed, 11 Nov 2020 00:15:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJwZFurfCqMHH543qYFp6W4ZVEIYyP/c3RzXXCZzIR3rNP8sWE34n7mHptAYwu+Fa0IoAKR8 X-Received: by 2002:a17:906:3e8f:: with SMTP id a15mr15821213ejj.57.1605082547014; Wed, 11 Nov 2020 00:15:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605082547; cv=none; d=google.com; s=arc-20160816; b=AzHeJ1Rnmzw7wcAeJKolVIxXQGRuxoy/x32iM1Dq2vqIRjtZOQBu1rE2O44d9fRj78 GR6gDF7wPBLpU9NdTNgoI8kzHjIV/W+r4c/+ojZuFHwhwT0gYafslNH7Ao49ad0oxVz4 mLuiRJ8nMHcPq/0RPNkOKV6S0mHoDLrz1liCe3LuExY6VJhd1wjDErGg1gT2zcSv/s5l zRjXQ9khvIcpKwBlZkO72ECysSMbtnkPCtWhuD/QcLTtxpC5kawcnnPTQOWOYgr5TiD6 KaIWJSwfEcEFkmY85TkKb03WPQurhJyZKP5wqD9D0fFdKyXW9Em/28BvljEs2FJ4l2AD EAqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=C6rePdJhHdBIcifQ3bJZk8I1df2ka7hXQCergLELkL0=; b=XfjwosgjTarRhN+gMYUksXErLxyliQ783Ilymci2eaFM2948InLEQc3GJYQzBz0FaU CKEGvHGcjXHyr7tI9UYiu1INS7Cmo09NgTInav4Cjkg2IwgLoQ6l9BqObsNnfCtWiZDC 2Ef0B8S9anl3X+qgU0yeuI3ki8qlGGVQK8+2uyXS5Fe2q5BqNn900GHZYmC8PQ6p84Fx DSeuj1XEeQybYa2B52IN6jTS8ChcswtA8GEEzPwoLq0eR/vRf4YIXqlhptkBzG+xH6Nn yEVz7Yvl5eF1fzf8OODFR7234nrLosYG9dIvTSn3VHrWfKlUKLmHaUEbGGsijqoB+0Rq B4BA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hr29si985138ejc.464.2020.11.11.00.15.23; Wed, 11 Nov 2020 00:15:47 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726126AbgKKIN2 (ORCPT + 99 others); Wed, 11 Nov 2020 03:13:28 -0500 Received: from mx2.suse.de ([195.135.220.15]:48932 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725468AbgKKIN2 (ORCPT ); Wed, 11 Nov 2020 03:13:28 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 73CA3ACC5; Wed, 11 Nov 2020 08:13:26 +0000 (UTC) From: Thomas Renninger To: Viresh Kumar Cc: Rafael Wysocki , Jonathan Corbet , linux-pm@vger.kernel.org, Vincent Guittot , Shuah Khan , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cpufreq: stats: Switch to ktime and msec instead of jiffies and usertime Date: Wed, 11 Nov 2020 09:13:24 +0100 Message-ID: <2047155.4hzcE6bcFl@c100> In-Reply-To: <20201111051350.qxevqcca5775h2xa@vireshk-i7> References: <0e0fb542b6f6b26944cb2cf356041348aeac95f6.1605006378.git.viresh.kumar@linaro.org> <1832747.5iOEhN7m9D@c100> <20201111051350.qxevqcca5775h2xa@vireshk-i7> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Mittwoch, 11. November 2020, 06:13:50 CET schrieb Viresh Kumar: > On 10-11-20, 13:53, Thomas Renninger wrote: > > Am Dienstag, 10. November 2020, 12:07:37 CET schrieb Viresh Kumar: > > > 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:1200000 399 > > > > > > The results look like this after this commit: > > > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:1200000 3830 > > > > How would userspace know whether it's ms or 10ms? Again: How would userspace know whether it's ms or 10ms? > > whatabout a new file with the same convention as cooling devices (adding ms): > Keeping two files for same stuff is not great, and renaming the file > breaks userspace ABI. No exactly the other way around: - Renaming, breaks the userspace ABI. - Two files would be the super correct way to go: - Deprecate the old file and keep the 10ms around for some years ./Documentation/ABI/obsolete - Add the new interface and document it in: ./Documentation/ABI/testing As this is about a minor cpufreq_stat debug file, it is enough if you rename to: > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state_ms Ideally document it in ./Documentation/ABI/testing But I guess for this one this is also not mandatory. Then userspace can do: MS_FILE="/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state_ms" 10MS_FILE="/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state" if [ -r "$MS_FILE" ]; then POLICY0_MS=$(<"$MS_FILE") echo "Found ms stats file" elif [ -r "$10MS_FILE" ]; then echo "Found 10ms stats file, converting..." POLICY0_MS=$(<"$10MS_FILE") POLICY0_MS=$(echo "$POLICY0_MS 10 /" |dc) else echo "cpufreq stat not compiled in?" fi > I am not sure what's the right thing to do here. Use a new *_ms name. If you are unsure how many people this still might use, keep the old file and mark it deprecated and remove it in some years. You could also add: pr_info("%s userspace process accessed deprecated sysfs file %s", task->comm, OLD_SYSFS_FILE_PATH); To find other userspace apps making use of it. ... > I already fixed this recently and stats don't appear empty for fast > switch anymore. Then cpufreq_stats could be a module again? Thomas