Skip to content

[CmdPal][PerfMon] Use % Processor Time for system CPU dock#47864

Open
Knyrps wants to merge 1 commit into
microsoft:mainfrom
Knyrps:fix/cmdpal-cpu-utility-46381
Open

[CmdPal][PerfMon] Use % Processor Time for system CPU dock#47864
Knyrps wants to merge 1 commit into
microsoft:mainfrom
Knyrps:fix/cmdpal-cpu-utility-46381

Conversation

@Knyrps
Copy link
Copy Markdown

@Knyrps Knyrps commented May 13, 2026

Summary of the Pull Request

The system-wide CPU counter in the Command Palette Performance monitor used % Processor Utility, which is scaled by % Processor Performance and is intentionally unbounded above 100% when cores boost above their nominal base frequency. Under load this produced values like 144% in the dock, as reported in #46381.

Switch to % Processor Time — the same counter Task Manager renders — which is naturally bounded to 0-100%.

The per-process branch is unaffected; it already divides by Environment.ProcessorCount and continues to use % Processor Time, so individual process readings remain correct.

PR Checklist

  • Closes: Bug: CPU Usage stats in Dock goes beyond 100% #46381
  • Communication: I've discussed this with the team/maintainers via the linked issue.
  • Tests: Manually tested locally. Built Microsoft.CmdPal.Ext.PerformanceMonitor and the full CommandPalette.slnf (Debug|x64). Verified the built DLL contains % Processor Time and no longer contains % Processor Utility.
  • Manual tests: Ran the rebuilt dev build under sustained CPU load; the system CPU figure now stays bounded to 100%.
  • Localization: Not applicable — counter name is an OS API string, not user-visible text.

Detailed Description of the Pull Request / Additional comments

% Processor Utility is documented by Microsoft as deliberately unbounded; it represents an "effective" utilization that accounts for turbo/boost frequencies. It is well-suited for billing/capacity contexts but not for a "% of CPU used" UI element where users expect a 0-100% reading consistent with Task Manager and Resource Monitor.

_procPerformance (the % Processor Performance counter) is retained because it is still used by CpuSpeed to compute the live frequency display, so removing it would regress the speed readout.

Before

System CPU dock showed values >100% under load (reported 144% in the issue).

After

System CPU dock is bounded to 0-100%, matching Task Manager.

The system-wide CPU counter used `% Processor Utility`, which is scaled by
`% Processor Performance` and is intentionally unbounded above 100% when
cores boost above their nominal base frequency. Under load this produced
values like 144% in the dock.

Switch to `% Processor Time` — the same counter Task Manager renders —
which is naturally bounded to 0-100%. The per-process branch is unaffected;
it already divides by `Environment.ProcessorCount` and continues to use
`% Processor Time`.

Fixes microsoft#46381
@niels9001 niels9001 added Product-Command Palette Refers to the Command Palette utility CmdPal - Dock Issues related to the Command Palette Dock labels May 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CmdPal - Dock Issues related to the Command Palette Dock Product-Command Palette Refers to the Command Palette utility

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants