[ViderStar]

Processes with no DRM engine time are only rescanned every 5 seconds (gpu_activityMs). When such a process starts using the GPU, GPU_readProcessData() takes the busy time accumulated since that last scan but divides it by one refresh interval (monotonicMs - prevMonotonicMs), so the first GPU% value is inflated by up to 5s/delay.

The fix remembers when the previous scan happened and divides by the time since then. For processes that were scanned on the previous refresh nothing changes.

Tested on Linux (Debian trixie container) with htop built --with-proc=/fakeproc: a fake PID whose fdinfo has an i915 client with drm-engine-render at 0 ns, which after ~2 s starts growing at 50% of wall time, -d 10, columns PID / GPU% / GPU_TIME, screen read with tmux capture-pane every second:

before: 0.0  0.0  0.0  0.0  147.4  49.3  49.3  49.4  55.2 ...
after:  0.0  0.0  0.0  0.0   29.2  54.5  49.2  48.8  48.7 ...

(29.2% is the average over the 5 s since the previous scan, 1.47 s busy.)

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Repository UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 8269286e-ac8b-4ba7-86dc-e164bebca929

Commits

Reviewing files that changed from the base of the PR and between 394b4a3 and 400e9ea.

Files selected for processing: 1

• linux/GPU.c

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 7 remain after this review.

Walkthrough

GPU_readProcessData now saves the GPU activity timestamp and uses it for the five-second scan throttle. For utilization, the interval starts at that timestamp when available. Otherwise, it starts at the host’s previous monotonic time.

Suggested reviewers: cgzones

Priority: Normal

Change: Bug fix

Merge Risk: Minimal · up to 400e9

No actionable merge-blocking risk is established for this change.

- [ ] Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{A saved timestamp marks the scan
The throttle checks its value
Utilization spans that time
Or starts from the host’s prior mark
Two timing paths now share one guide
The GPU scan proceeds on time}

_{Comment @coderabbitai help to get the list of available commands.}

[ravi-arnan]

Nice catch on the DRM fdinfo rescan timing.

Reviewed the diff in linux/GPU.c:

1. Math & timing verification: When an idle process is throttled behind lp->gpu_activityMs != 0 && host->monotonicMs - lp->gpu_activityMs < 5000, the subsequent non-zero new_gpu_time indeed represents accumulated work over the entire scan interval (~5s), not the single refresh delta (host->monotonicMs - host->prevMonotonicMs). Dividing by (lastScanMs ? lastScanMs : host->prevMonotonicMs) properly normalizes the utilization over the real measurement window.
2. Transition back to active: Because lp->gpu_activityMs is reset to 0 at line 224 when active, subsequent consecutive refreshes correctly evaluate lastScanMs == 0 and fall back to host->prevMonotonicMs, keeping real-time reporting accurate.
3. Div-by-zero safety: host->monotonicMs - lastScanMs >= 5000 is guaranteed by the earlier guard at line 88, so monotonicTimeDelta remains strictly positive when lastScanMs != 0.
4. Build verification: Compiled cleanly under Linux GCC with htop's full strict warning set (-Wall -Wextra -Wcast-align -Wshadow -Wnull-dereference etc.) with 0 warnings.

LGTM.

[ViderStar]

@BenBE @natoscott gentle ping: could one of you take a look when you have time? It fixes inflated per-process GPU usage after the fdinfo rescan throttling.