[DjDeveloperr]

Follow-up to #505 (stacked on it). This closes the case #505 listed as its remaining limit: a closed context whose compute side is clean, but whose render pair holds executed, unstamped work.

The case

In #505 a failed context is killed through its faulted compute queue. Some closed contexts have no such queue. Their failed compute command was already retired on the firmware's fault record (#496), so no compute queue is left to carry a kill, yet their render pair holds work the firmware ran but never stamped. That work is released only by a kill, so the context, its pairs and its memory stayed allocated until the GPU firmware stopped. In #505's two-client ray-query run these were the 4 teardowns left pending.

What this change does

• A render-only kill. A closed context qualifies when all of the following hold:

  • it has been closed for 250 ms, the same delay a quarantined compute queue gets, so ordinary retirement goes first;
  • every compute queue is idle for it, with no switch from it and no kill already published through one;
  • every render pair of it is idle or has executed all of its commands, and at least one holds such executed, unstamped commands.

  The kill names one of the context's own render queues that its scheduler page lists, never queues 0 and 1.

• The rules of drm/asahi: kill faulted G17 contexts before freeing their render work #505 apply unchanged:

  • The held pairs stay held for the kill, and their memory is released only once the scheduler page reports it.
  • The kill waits for a moment without other contexts' compute, unless GPU memory is within an eighth of the device limit.
  • A kill names only queues of this context.

• Refusals are safe and visible. If the scheduler page names a queue outside the context, if the held pairs have no single owner, or if admission can't hold them, the kill isn't published. The refusal is counted once per context and ends that context's wait. debugfs reports render_kills published= acknowledged= refused_scope= refused_owner= refused_hold= waiting= longest_wait_ms=.

• Exact acknowledgement. A render-only kill is acknowledged only by its own cookie, once. The asahi_g17_teardown tracepoint gains kind 7 (render-only kill published), and kind 4 marks a render-only acknowledgement.

Measured effect

Neo (A18 Pro), Mesa agx3.

Two-client ray-query pairs run, 10 minutes (the run where #505 left 4 pending; measured on the first revision of this change, which differed only in how refusals were counted, and none occurred):

	#505	with this change
faults	51	53
compute kills (all acknowledged)	51	53
render-only kills (all acknowledged)	—	4
GPU recoveries	0	0
EBUSY / capacity refusals / render-kill refusals	0 / 0 / —	0 / 0 / 0
teardowns pending / pairs quarantined after the run	4 / 4	0 / 0
GPU memory peak (device limit 5083 MiB)	4440 MiB	4204 MiB
gnome-shell	alive	alive

Both runs had 4 compute watchdog timeouts between the two traversal clients. That is the long-job contention case #499 addresses, and neither branch includes #499.

Five-lane stress, 10 minutes (render, render2, long ALU, churn and global-priority CTS, plus two ray query geometry-shader loops):

	#505	with this change
faults	52	48
compute kills (all acknowledged)	15	8
render-only kills (all acknowledged)	—	2
GPU recoveries / firmware crashes	0 / 0	0 / 0
EBUSY / capacity refusals / render-kill refusals	0 / 0 / —	0 / 0 / 0
teardowns pending / pairs quarantined after the run	0 / 0	0 / 0
GPU memory peak (device limit 5083 MiB)	4372 MiB	3192 MiB
gnome-shell	alive	alive

An integration build of the stack without this change left 2 teardowns pending on the same harness.

The churn lane's concurrent.cr (queues, depth 4) timed out in 18 of 28 runs here, against 11/27 on #505, 10/22 on #496 and 6–12 of 22–28 on other builds of the same harness. The timeouts are not tied to this change's kills. None came within 30 s after a render-only kill (those were at 336 s and 695 s; the closest timeouts were at 280 s, 372 s and 688 s). The rate was the same whether kills were waiting or not: 12/19 with kills waiting, 6/9 without. This test starves when long traversal jobs hold the GPU, which is the contention case #499 addresses.

Testing

• Regression gate on the final build: PERFORMANCE-REGRESSION-PASS.
• Targeted CTS on the final build (5368 cases): 4687 pass, 681 not supported, 0 fail. The two host-built 1M-primitive ray tracing cases also pass serially, with 0 asahi kernel errors and nothing pending afterwards.
• KUnit (asahi_g17*, 120 cases), new tests:
  • a render-only kill names an own listed queue, never queue 0 or 1;
  • only the exact cookie acknowledges a render-only kill, once;
  • held pairs with mixed owners are refused.