From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0234144998E for ; Tue, 18 Aug 2026 09:55:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787046953; cv=none; b=HJupjG9VIoFKYoERwQZpG3LO0EqgZbfh2Zam7QtLVJfmVzSjWD0/QJFTAANM/7xLO/11srk4BEmgVfCJuonPgNZQtLp8h3remDvJJXi9jWPXSn1AtxqpFK7z8FdG9f9xbODsFjKpEp0NySseM75dBlsjhGbjp0yt+X9YDgBC3No= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787046953; c=relaxed/simple; bh=uSjLGwM8f8rLIyQ8IaLP4sQuqoay2liq4KxW5tYEfKY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=NCpNKJ0hoqzkVOP4dVIu8O1NyWEEUvwBNDZu4wpfbFHYEmwcmYggjXtV/WfqY/OiItWCkGNUIHQ1qzDVGb0Oa+sMDsTCoohhfDNALmDtjh4/1kTbZvYFJ1/gAdLa0qAh3Zdm1DwpOFwqmRgu7Qf9i9yNxua9IUxECmk24/kZab0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Cil1Wf2A; arc=none smtp.client-ip=209.85.214.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Cil1Wf2A" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2ce7d2adef4so11005955ad.3 for ; Tue, 18 Aug 2026 02:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787046951; x=1787651751; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=MvZfYYEAxhzIIn9xadj0EwR+EuQol+UjVFty09Z5sHc=; b=Cil1Wf2A+RxG79R7+4Ot2jXo9HDGeCUuDKz2U76yqhtGxnY0pNqLQynw9EYf9OuB2m l+zhmoBeEH27R3/jSVUrr3iouup10ua6agcezrjssq95OIEIJJlPFJLlHGFpkkcxfUAP Xucqs+/0zrHSdpUGEr6WopAJD1ahBEHIxQ2guL73iN5d10Ug4Aa69DulTRT/Ar/bBZRG IMfOeqe9mH9aeKH8ML8HofWYqWa9MiidFaLpp+P3SOFv6lu+myieWgYehM3GJ6jjXSJN vXNNN2E1EXSAaivASFMdtZZwMG/j3At/GWhAcuTjyi7mYDXj9/D2FAK/x17QjA519cv3 GB0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787046951; x=1787651751; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=MvZfYYEAxhzIIn9xadj0EwR+EuQol+UjVFty09Z5sHc=; b=U0suZVdqf/ddP85tP1J4YJIW/BRm+JqNIPloFQqo7WJ6D+BbU3yJxagsSHtH/GKVAP cQPd4Sb/oTseAscwE0OVN4/p56+XRoid3vRPQgYA3s/VbnXAVz4nxvDse0xZA/9yOa5B cid3fpCArFYDtRWAWBdC5Kihb2Pu1NcS/qdEDPxD2z0JS5UqL8VArtX2KbjteVlRggSf dTaQAhQofJVq8uNPtVZ5Tuq2NucoNDptyOZhNfytFuGizJrhJ22qOv46mu5Gqmsf7t2N McFO/uSxhd6OTNW9y+s/6H+4BNWmXe4SxoBTZm0h1U5F7DpDx8tsNch4m6FW6xfDyzIe s0WA== X-Forwarded-Encrypted: i=1; AHgh+RrEKFUFUBfFOt6cVRe6YeNS4I6x05c/JLXC1K6g9jg3CLEqMO+Pxz77KYPn89yVpJUhkA/1SzIioTfLtx0=@vger.kernel.org X-Gm-Message-State: AOJu0YxJl8yEJ3rhbEMoGfGnlbpUwfoWOJE0Iaj+8yat5ia9yiWhfP5p 9NsljKXKQysEwHirfIXqryHVJVlsWxAmRPQbrgkusLtcBs3PSqdgQ0kk X-Gm-Gg: AR+sD12tEALQvIsFx6z7gKO5kZX/21Ui6wvv6xLFkN4nt1S93B49TJUpb8MA74DHUPG UfP5X4SArewfXhXo9YXpZIAyVAWDg+NCtfp0eAn6OG3bbGa4I1Foj7YoT2RwFbOiY+1gSGxWgLN EnNF/vjq05DxI9lU4Ptm5Z3kjlOaP3Rh6JYoEqOXSK+b2Nm76Ua5qUpRL4Mbmxec0tqb/2/s7zt 0URq1PXrV+Cp6zIWAybbV/38krQYc6s42GqybJRSIl4OkrUewwCzv0RXRXuASVh6KQ/U/y0a8Qr dHMwwfw7G4YfvErJW1M/ItQbi6HBEPaOXIzOPStz3Ivp5H9gSo+VLeiEtCn6Ks+k4k3Pn/lRQbt QY9mZWUv0YTyCv3Xa5hghDQ/Bye1C4dCqvNjf3aZoNqNVwDxjuHGK+y8sRhGsL11+fCg21M1WWw dG+6vMDxcJL2oXQlS9bvZdJ7EZ8EWvK8CpW2Bki6Ra5hbaMuD0wjLF9spfIQrIMrRhvuEzBnF40 31YemdH/Po= X-Received: by 2002:a17:903:32cb:b0:2ce:93a3:c168 with SMTP id d9443c01a7336-2d3b085db2fmr370693375ad.7.1787046951357; Tue, 18 Aug 2026 02:55:51 -0700 (PDT) Received: from volcano9f8e-host.amd.com ([165.204.217.251]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-326794c0c94sm29532295eec.9.2026.08.18.02.55.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 02:55:50 -0700 (PDT) From: Hemanth Selam To: Thomas Renninger , Shuah Khan , "John B . Wyatt IV" , John Kacur Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Hemanth Selam Subject: [PATCH 0/1] cpupower: monitor: Show how a counter value is exported Date: Tue, 18 Aug 2026 15:25:37 +0530 Message-ID: <20260818095538.1196953-1-hemanth.selam@gmail.com> X-Mailer: git-send-email 2.43.7 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi, this picks up the ToDo in list_monitors() which asks to show more of the capabilities of a counter. "cpupower monitor -l" tells the name of a counter, the processor hierarchy level it covers and its description, but it does not tell how the value of the counter is exported. That is not obvious from the description either: most counters are a percentage of the time spent in a state, while for example the Mperf "Freq" counter reports MHz and the RAPL zones report micro Joule. Without that information the numbers of a measurement run are hard to interpret. The value type is now printed behind the hierarchy level, using the square bracket notation the hierarchy level already uses: [%] The counter is a percentage of the time spent in the state. [abs] The counter is an absolute value, its unit depends on the counter, MHz for "Freq" or micro Joule for a RAPL zone. The man page is updated in the same patch, right below the description of the [T], [C], [P] and [M] hierarchy levels. Note that "%" and "abs" are deliberately not single letters: [C] and [P] are already taken by the Core and Package hierarchy levels, so reusing them would render counters as "[P] [C]" or "[C] [P]", which cannot be read unambiguously. The second half of the ToDo, showing the time granularity of a counter, is not implemented. There is no per state granularity information today, only the per monitor overflow time which is already printed. It would need a new cstate_t member every monitor has to fill in, so the ToDo is kept, narrowed down to what is left to do. Tested with the Mperf and Idle_Stats monitors: $ cpupower monitor -l Monitor "Mperf" (3 states) - Might overflow after 922000000 s C0 [T] [%] -> Processor Core not idle Cx [T] [%] -> Processor Core in an idle state Freq [T] [abs] -> Average Frequency (including boost) in MHz Monitor "Idle_Stats" (3 states) - Might overflow after 4294967295 s POLL [T] [%] -> CPUIDLE CORE POLL IDLE C1 [T] [%] -> ACPI FFH MWAIT 0x0 C2 [T] [%] -> ACPI IOPORT 0x814 Measurement runs, "cpupower monitor -i 1" and "cpupower monitor -m Mperf -i 1", print the same output as before, only the listing changed. Thanks, Hemanth Hemanth Selam (1): cpupower: monitor: Show how a counter value is exported tools/power/cpupower/man/cpupower-monitor.1 | 8 +++++++ .../utils/idle_monitor/cpupower-monitor.c | 22 ++++++++++++++++--- 2 files changed, 27 insertions(+), 3 deletions(-) -- 2.43.7