lparstat Displays Negative Values for %idle in "Actual" Section #103
Comments
tyreld
pushed a commit
that referenced
this issue
Feb 25, 2025
In certain scenarios, the %idle PURR metric displays negative values [1], while %busy PURR exceeds 100% giving users false impression of resource utilisation. This occurs when delta_purr becomes greater than delta_tb, causing the following expression to yield a negative value, particularly during 100% system utilization for %idle PURR: %idle = (delta_tb - delta_purr + delta_idle_purr) / delta_tb * 100; Without change: ./lparstat -E 1 30 System Configuration type=Shared mode=Uncapped smt=8 lcpu=20 mem=208057792 kB cpus=42 ent=2.00 ---Actual--- -Normalized- %busy %idle Frequency %busy %idle ------ ------ ------------- ------ ------ 103.88 -3.88 2.75GHz[ 98%] 101.80 0.00 103.46 -3.46 2.67GHz[ 95%] 98.28 1.49 101.53 -1.53 2.74GHz[ 98%] 99.50 0.51 103.41 -3.41 2.70GHz[ 96%] 99.27 0.37 The delta_tb is computed using get_scaled_tb, which calculates the timebase for a given time difference. Previously, nanoseconds were ignored in the calculation of time difference, which led to delta_tb being underestimated. This patch addresses the issue by incorporating nanoseconds into the time difference, ensuring precise calculations. Also, rename get_time() to get_time_ns() to denote it returns time in nanoseconds. get_delta_time() is introduced as a wrapper to get delta time in seconds. With change: ./lparstat -E 1 30 System Configuration type=Shared mode=Uncapped smt=8 lcpu=20 mem=208057792 kB cpus=42 ent=2.00 ---Actual--- -Normalized- %busy %idle Frequency %busy %idle ------ ------ ------------- ------ ------ 99.52 0.48 2.74GHz[ 98%] 97.53 2.66 99.53 0.47 2.71GHz[ 97%] 96.54 3.67 99.49 0.51 2.71GHz[ 97%] 96.51 3.87 99.51 0.49 2.70GHz[ 97%] 96.53 3.90 99.48 0.52 2.69GHz[ 96%] 95.50 4.38 [1] #103 Signed-off-by: Saket Kumar Bhaskar <[email protected]> Signed-off-by: Tyrel Datwyler <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
—————————Steps to reproduce the issue———————
Step 1: Boot the lpar in shared mode with any EC vs VP ratio.
Step 2: Build and run the upstream lparstat,
(https://github.com/ibm-power-utilities/powerpc-utils.git)
Step 3: Run the ebizzy workload from either LTP or from below link,
(Source 1: https://sourceforge.net/projects/ebizzy/files/ebizzy/0.3/ebizzy-0.3.tar.gz
Source 2: LTP)
Step 4: Run the command below with load.
Ex: lparstat -E 2 2
——————With ebizzy workload—————
With distro lparstat;
(lparstat - 1.3.10)
lparstat -E 2 2
System Configuration
type=Shared mode=Uncapped smt=6 lcpu=12 mem=298501056 kB cpus=34 ent=12.00
---Actual--- -Normalized-
%busy %idle Frequency %busy %idle
100.01 0.00 3.22GHz[ 93%] 93.00 0.00
100.00 0.00 3.22GHz[ 93%] 93.00 0.00
With Upstream (powerpc-utils)lparstat:
(lparstat - 1.3.13)
./lparstat -E 2 2
System Configuration
type=Shared mode=Uncapped smt=6 lcpu=12 mem=298501056 kB cpus=34 ent=12.00
---Actual--- -Normalized-
%busy %idle Frequency %busy %idle
101.54 -1.54 3.22GHz[ 93%] 94.44 5.19
100.39 0.00 3.22GHz[ 93%] 93.36 6.22
The logs clearly indicate that upstream powerpc-utils is having issue while showing the “Actual” %idle value, Where its showing the negative values.
The text was updated successfully, but these errors were encountered: