diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-30 20:04:30 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-30 20:04:30 -0400 |
| commit | 6ec799c462518c1f265a12095b28708bf10785af (patch) | |
| tree | 83c29071451cb547674f98a2c66739f9a80154bb /kernel/main.c | |
| parent | b77e75483b811420687bc32e6484162b499aba2f (diff) | |
| download | open-iov-6ec799c462518c1f265a12095b28708bf10785af.tar.gz open-iov-6ec799c462518c1f265a12095b28708bf10785af.zip | |
sema-svc: deliver UVM CE tracking releases without host-side pins
The runtime client's registration stalled when no guest-side pin scanner was
running: the content rescue refused to run before the pool semaphore was
translated (its expected payload was unlearned), and unreadable CE entries
were consumed after two failed rescues ~40 ms apart, dropping the client's
wait. The push pages then could not be found within the entry's grace window.
- rescue: drop the learned-payload gate (the matcher only needs the channel
rank and the release shape); keep unreadable CE entries pending for
sema_ce_grace_ms instead of consuming after a fixed attempt count
- expected payload: re-learn from the pool whenever it advanced (a deferred
release could land after the first read, leaving the expectation stale)
- matcher: require the expected payload exactly and validate the read-back
stream carries it, so a recycled page of an older push cannot be pinned
- scan: descending full-range pass (the work allocations live in the high
RAM block) plus a +/-512 MB near pass around the verified push-buffer base
- releases decoded with an untranslated semaphore are queued and applied
when the page appears (svc_pending_add on both decode paths)
- a CE push that reads as a plausible stream but carries no release for the
channel is re-routed through the rescue instead of silently consumed
- new module param sema_rel_recover (default off): after grace + rescue,
apply the channel's expected tracking value so the client's wait clears;
counter-visible as releases_recovered, distinct from sema_fake_rel
Evidence: fresh boot, real releases, no host watcher, no kprobes - the six
UVM CE first pushes are found by content rescue, their releases applied, and
the client reaches cudaGetDeviceCount rc=0 (it then waits for the third
push, which this change routes to the rescue).
Diffstat (limited to 'kernel/main.c')
| -rw-r--r-- | kernel/main.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/kernel/main.c b/kernel/main.c index dd38402..fa88d19 100644 --- a/kernel/main.c +++ b/kernel/main.c @@ -2443,6 +2443,8 @@ MODULE_PARM_DESC(sema_gr_rings, "Auto-discover+pin GR channel rings (default 1)" */ module_param_named(sema_fake_rel, gsp_sema_fake_rel, bool, 0644); MODULE_PARM_DESC(sema_fake_rel, "Acknowledge unreadable CE releases directly (default 0)"); +module_param_named(sema_rel_recover, gsp_sema_rel_recover, bool, 0644); +MODULE_PARM_DESC(sema_rel_recover, "Recover unreadable CE releases after grace + rescue (default 0)"); /* * Skip executing the pushed work (CE memsets/copies) while still applying the |
