A High-Priority CUDA Stream Cannot Interrupt Work Already Running

Separate selecting pending work from interrupting running work

NVIDIA's archived CUDA Driver API 13.1.1 reference for cuStreamCreateWithPriority describes a scheduling hint: higher-priority work is preferred when possible, without preemption of running work or a functional execution-order guarantee. This is the explicit 13.1.1 wording, on a page last updated January 12, 2026; it is not presented as the latest release.

The current CUDA Programming Guide makes the same priority qualification. It separately describes sequential execution within a stream and resource-dependent selection of available tasks across streams.

That distinction determines what a supplier's priority feature establishes. Selecting an eligible task for available resources and displacing work already using resources are different actions. Giving urgent work a higher priority does not turn the selection hint into an interruption mechanism.

References: [N1][N2]

Keep prerequisites and transfers in the urgent request

Priority leaves required ordering intact. The current guide describes cross-stream event waits that delay subsequent commands until the event completes. An urgent kernel waiting for a required input or preceding operation still has that dependency; its business importance does not supply the missing result.

Transfer coverage also needs an explicit answer. Both the 13.1.1 Driver API and the current Runtime API 13.4 reference qualify their documented implementation: stream priority affects compute kernels, with no effect on host-to-device or device-to-host memory operations. The current guide likewise cautions against assuming transfer prioritization.

If the caller needs input transfer, computation and a returned result, ask the software supplier which stages its priority claim actually covers. A compute scheduling feature alone leaves the rest of that request path unexplained.

References: [N1][N2][N3]

Work through 1 ms of service demand and a 7 ms response

Consider a wholly fictional model with one serial execution resource. Low-priority task L occupies that assumed resource from time 0 to time 8 ms. High-priority task H becomes ready at time 2 ms and needs 1 ms of service after starting. The model assumes no overlap, interruption, transfer time or other overhead.

Stipulate that H is selected immediately after L finishes. H starts at time 8 ms and completes at time 9 ms. Its wait after readiness is 8 - 2 = 6 ms; adding its 1 ms of service gives 7 ms from readiness to completion.

If the invented requirement is completion within 1 ms of readiness, its finish would need to be at or before time 3 ms. This stipulated schedule misses that target even though H itself needs only 1 ms of service. Labeling H urgent does not remove the occupied interval.

H running next is an assumption of the example, not a guarantee obtained from CUDA priority. These invented times establish why service demand and response duration differ. They are not measurements of a GPU.

A real GPU may overlap eligible work when its resources and execution conditions permit. The serial-resource assumption does not mean every executing kernel occupies an entire GPU until completion. The 9 ms finish is neither a CUDA-mandated schedule nor a bound for other systems.

References: [N2]

Ask what happens when urgent work arrives during competing execution

Suppose a supplier provides only a high-priority-stream flag and a report that the urgent kernel takes 1 ms in isolation. The flag identifies a runtime feature. The isolated duration describes its reported execution interval. Neither supplies the missing observation in the worked case: when urgent output becomes available after the request encounters competing work.

Define that required finish before evaluating the offer. If the requirement begins when a caller submits a request, readiness of its GPU work may occur later. A readiness-to-completion result then covers a narrower interval. Include required input handling, dependencies, transfers and result delivery wherever they fall inside the buyer's declared request boundary.

Ask for evidence on the proposed application and system with the relevant competing activity present. Retain the GPU allocation, application, CUDA and driver versions, urgent request sizes, arrival pattern and competing-work description. In particular, identify whether the evidence includes urgent arrivals while the competing computation is already executing. A run where background work remains idle leaves that operating case unanswered.

Match the reported population to the requirement. An average does not establish that every request meets a limit, and a percentile needs its stated population and observation interval. Have the application owner identify missed completions and explain what the evidence supports under the offered conditions.

A priority flag as the supplier's only latency evidence leaves the urgent completion requirement unresolved. It does not prove that the runtime is unsuitable. Request the missing evidence before treating the feature as an answer to that requirement.

Keep allocation and timing evidence attached to their own decisions

If the offer promises dedicated or isolated GPU resources, ask for the actual allocation boundary. A stream priority field supplies no new hardware partition or reservation. The linked MIG and time-sliced vGPU guide explains how to compare those resource entitlements.

Use the CUDA timing guide to interpret host, device-event and caller intervals in the supplied evidence. Use the CUDA graph guide when the claim concerns reduced recurring launch work. Those mechanisms can matter to the same application, but their labels do not fill the urgent completion evidence gap identified here.

Bring selected equipment to a separate physical deployment inquiry

If the selected system also needs physical installation, Leviathan's Complete Physical Infrastructure Deployment service can scope receiving, rack integration, onsite installation, IT cabling and handoff records. Use the related service and project-inquiry links with a nonconfidential equipment summary, site, target window and receiving team.

Keep runtime design, profiling, driver tuning and application acceptance with the appointed software and platform owners. This article supports an equipment decision; it is not a field procedure or work approval, and those software tasks are not Leviathan's physical deployment service.

References: [L1]