Repository navigation
soc: apple: clpc: hand the T8140 GPU floor back 100 ms after the PMP stops limiting - #245
DjDeveloperr wants to merge 1 commit into
Conversation
…stops limiting The GPU floor stayed released for a second after the PMP last limited the DCS. Light GPU work that followed heavier work therefore ran without the floor for up to that second: on Neo, compute.light d1 took 148-151 us instead of 102.7 us for the first 0.5-0.75 s of a run, before the floor came back. Under sustained heavy rendering the PMP limits the DCS again within much less than that, so a 100 ms hold keeps the floor released there while the light work that follows gets it back almost at once. (cherry picked from commit 51350a0) Signed-off-by: DjDeveloperr <hey@djdev.me>
|
CI is green on d93318c (plan, self-test, compile, commits, device trees, KUnit, package, boot, host tests). |
maralcbr
left a comment
maralcbr
left a comment
There was a problem hiding this comment.
Thanks @DjDeveloperr, this is the right trade. With 1 s, the light work that follows a heavy row pays for the whole hold, and 100 ms still sits well above the 4 ms sample period. No blockers.
What I checked:
- The commit is identical to aurora-silicon 51350a0 apart from the
-xand sign-off trailers, and it only touchesAPPLE_CLPC_GPU_BACKOFF_MSand its comment (drivers/soc/apple/clpc.c:51-57). - Only T8140 sets
pmp_backoff(clpc.c:587), so T8132 returns early atclpc.c:293-294and is unaffected. apple_clpc_gpu_limited()reads the PMP's own vote (agent 0,clpc.c:296), not the combined floor, so putting our floor back can't feed into the limited test. At the shipped HZ=1000 the 100 ms is 100 ticks, so rounding isn't an issue.check-commits.pypasses locally (signed off). The only full checkpatch error isGIT_COMMIT_IDon the(cherry picked from commit …)line, which is git's own-xformat, so I'd leave it. CI is green,ci / resultincluded, with package, boot and KUnit passing. KUnit has no CLPC suite, so the hardware numbers are what qualify this.
Nits, fine as follow-ups:
- PR body wording. "stays on the throttled floor for the rest of the hold" reads backwards: during the hold the GPU floor is released (
clpc.c:328-331), which is why light work runs slower. The commit message has it right ("ran without the floor"). Suggest: "runs without the GPU floor for the rest of the hold". - Heavy render at 100 ms vs 1 s. The AsahiLinux#464 notes give render.heavy d4 at 100 ms (672.4 vs 689.2 µs) and at 1 s (666.5 vs 679.9 µs), but against different baselines. "the floor doesn't flap" is the one claim the numbers don't show directly. If you're on the Neo again, a run of render.heavy d4 over 90 s at 1000 and 100 ms in the same boot, with W and temperature, would settle it. A counter in the debugfs status for how often the floor comes back would make flapping visible too (
clpc.c:376-382). Optional.
Good to merge from my side.
|
Thanks. I fixed the PR body: it now says light work "runs without the GPU floor for the rest of the hold", as the commit message does. You're right that the flapping claim isn't shown directly; the two render.heavy d4 pairs were against different baselines. The run that settles it is render.heavy d4 for 90 s at 1000 ms and at 100 ms in the same boot, with package power and temperature. I'll post it here when the Neo is free. The debugfs counter for how often the floor comes back is a good idea; I'll do it as a follow-up so it doesn't change this approved commit. |
|
The bounded Neo experiment was inconclusive, so this run does not qualify for a lab approval or merge from me. The matched builds use integration base In A job The custom output ends after L0: 25,183 checked light dispatches with zero wrong words, but no completed heavy/recovery cycle, no checked render frames and no sustained phase. The helper group drained and cleanup passed. All 3,272 CLPC samples had zero update/read errors; no kernel fault stop was recorded. B was not run, and the temperature cutoff was not raised. There is therefore no A/B performance conclusion or patch defect established by this attempt. Neo is restored to its original |
|
@chriskearney thanks for the run. Zero wrong words over 25,183 light dispatches, and zero CLPC update or read errors over 3,272 samples, are good to see. On the guard: the J700's SoC routinely goes above 85 °C under sustained fill or render work. Our #263 qualification run went from 72 °C to 107 °C during render.heavy (#263 (comment)). So an 85 °C collector guard will trip within seconds of the first fill leg on this machine. That's expected behaviour, not a fault in either build. Some options, whichever suits your lab:
|
chriskearney
left a comment
chriskearney
left a comment
There was a problem hiding this comment.
Fresh matched A/B on Neo (J700/A18 Pro) completed. Functional checks and the sustained non-regression gate passed. The predeclared recovery verdict is INCONCLUSIVE; these runs do not qualify for my lab approval or merge.
A is 7.2.11-9-3504.3-ARCH at integration base 7e4fc9fe; B is 3504.4 with the exact d93318c4 delta. Config, DTBs, helper binary and installed graphics providers match. Verified CLPC disassembly differs only in the backoff comparison, 1000 versus 100.
The earlier 85°C-guard result remains unchanged. Before these fresh jobs, the collector policy was corrected to identify the six CPU thermal zones and stop at their 95°C upper passive trip, below the 110°C critical trip. Stock thermal/PMP controls stayed enabled; the collector made no sysfs control writes.
The 90-second sustained-fill workload gave:
| Measurement | A: 1000 ms | B: 100 ms |
|---|---|---|
| Median completion rate, final 60 s | 416/s | 412/s |
| Median SMC Total System Power, whole 90 s S phase | 10.288 W | 10.218 W |
| Maximum six-zone CPU temperature over the full run | 89.164°C | 92.056°C |
| Sampled floor-state transitions, whole 90 s S phase | 25 | 121 |
The 0.96% throughput reduction is within the frozen 3% bound; initial sustained-phase CPU temperatures differ by 0.585°C. One completion per 250 ms bin is about 0.96% granularity. Power and transitions are descriptive; the transition measurement uses 20 ms samples. No short eight-second heavy phase generated a fresh PMP latch, so that heavy-to-light recovery metric remained inconclusive.
A separate, freshly frozen ten-start-per-arm diagnostic produced:
| Startup result | A | B |
|---|---|---|
| Individually qualified starts | 2/10 | 3/10 |
| Recovery median from the last latch, among those starts | 1021.24 ms | 119.41 ms |
The observed delay follows the intended change, but the minimum was three qualified starts in each arm plus three elevated A controls. A supplied only two, so the formal verdict remains inconclusive. Excluded starts remain recorded with reasons; only fresh, individually qualified starts count. In several A starts, a later stream restart followed the latch; the driver retains that latch across restarts, but the frozen rule excluded it.
Both full-workload jobs (j1028-231425-2596, j1028-232740-5ed1) and focused jobs (j1028-234627-9518, j1028-235706-f129) passed boot/desktop checks, OMT with no regressions, and native GL/Vulkan readbacks before and after. All helper outputs recounted exactly with zero wrong words/pixels, zero CLPC read/update errors and no GPU/DCP/DART/CLPC fault stop. Every telemetry tick passed its policy/control recheck; groups drained and cleanup passed. The collector recounts and qualification agree across root and two independent readers. The custom renderer checks two final frames per heavy block.
Neo is restored to its original 7.2.11-8-1-ARCH. Protected boot files, original modules, configuration, packages, audio, agent and permissions match the backup. Staged tools and task files are removed, evidence retained, and the lease released.
|
@chriskearney thanks for the matched A/B with the 95 °C guard. The faster hand-back roughly multiplies the floor-state transitions by five in sustained fill: 25 → 121 over 90 s, about 1.3 per second. That's the expected cost of moving the backoff from 1000 to 100 ms. In your run, sustained throughput (416 vs 412/s), power (10.29 vs 10.22 W) and temperature stayed within your bound, while recovery after the last latch dropped from 1021 to 119 ms. If you or @maralcbr would rather have fewer transitions, we can add hysteresis: keep the fast hand-back after a burst, but require N consecutive samples before the floor changes state again. We'd measure that with your collector. Would you want that in this PR, or as a follow-up? |
Follow-up to #226: hand the T8140 GPU floor back 100 ms after the PMP stops limiting, instead of 1 s.
With the 1 s backoff, a light compute workload that follows heavier GPU work runs without the GPU floor for the rest of the hold. On the Neo, compute.light d1 ran at 148–151 µs instead of ~103 µs for the first 0.5–0.75 s of each round after a heavy row (aurora-silicon/linux AsahiLinux#464, issuecomment-6436396966). 100 ms still covers the PMP's limit/release cadence, so the floor doesn't flap, and the power win of the streaming gate is kept.
Qualified on the Neo (A18 Pro, J700) as the full aurora integration kernel plus this series:
The commit is a clean cherry-pick (-x) of aurora-silicon/linux 51350a0.