requestDevice() starts a permanent ~1-core busy loop on the main thread (Linux/Vulkan)

[kevinsproles]

Summary

Once adapter.requestDevice() resolves, the process starts a permanent busy pump on the main JS thread that never idles: ~1.09–1.10 cores of pure spin on Linux/Vulkan (NVIDIA), ~0.25 cores on macOS/Metal — with zero work submitted. It runs until device.destroy(), which stops it completely.

For a headless Node.js server-side rendering deployment this is severe: N worker processes burn N × 1.1 cores doing nothing. On one 32-thread host we measured 10.6 of 30.7 cores consumed by 9 completely idle processes.

Repro

node spin-repro.mjs (webgpu@0.4.0, Node 22):

// Does merely CREATING a device spin the Node main thread? Each stage measured identically.
const cpu = () => { const u = process.cpuUsage(); return (u.user + u.system) / 1e6 };
async function measure(label, ms = 8000) {
  const c0 = cpu(), t0 = performance.now();
  await new Promise((r) => setTimeout(r, ms));
  console.log(`  ${label.padEnd(34)} ${((cpu() - c0) / ((performance.now() - t0) / 1000)).toFixed(3)} cores`);
}
await measure("baseline (bare node)");
const { create, globals } = await import("webgpu");
Object.assign(globalThis, globals);
await measure("after import webgpu");
const gpu = create([]);
await measure("after create() instance");
const adapter = await gpu.requestAdapter({ powerPreference: "high-performance" });
await measure("after requestAdapter");
const device = await adapter.requestDevice({});
await measure("after requestDevice  <-- the tell");
const enc = device.createCommandEncoder();
device.queue.submit([enc.finish()]);
await device.queue.onSubmittedWorkDone();
await measure("after one empty submit");
device.destroy();
await measure("after device.destroy()");
process.exit(0);

Measurements

lifecycle stage	Linux/Vulkan, NVIDIA (driver 595.x; RTX 4060 Ti and RTX 4090)	macOS/Metal (Apple M4)
bare node	0.000 cores	0.000 cores
after import "webgpu"	0.000	0.000
after create()	0.000	0.000
after requestAdapter()	0.000	0.000
after requestDevice()	1.094–1.100	0.254
after one empty submit + onSubmittedWorkDone	unchanged	0.251
after device.destroy()	0.000	0.000

Thread attribution

Per-thread CPU from /proc/<pid>/task/*/stat on Linux: the spinner is the main JS thread (1.010 cores); libuv pool threads are ~0.038 cores each. In V8 CPU profiles of a busy server the spin shows up as processImmediate (up to 23.9% of self time), i.e. a setImmediate-driven "process events" pump that reschedules itself forever. That is consistent with the AsyncRunner/ProcessEvents polling loop in Dawn's dawn/node bindings never reaching an idle state — plausibly because the device.lost future is permanently pending, so there is always "a future in flight" and the runner never stops rescheduling.

The macOS-vs-Linux asymmetry (0.25 vs 1.1 cores) suggests the per-iteration cost is dominated by the backend's ProcessEvents/instance-poll cost, not the JS side — the loop itself appears to run at the same rate on both.

Ask

• Let the pump go idle when no user-visible future can make progress (e.g. event/callback-driven wakeup, or stop rescheduling when the only pending future is device.lost), or
• failing that, expose a knob (env var / create() flag) for the polling interval so servers can trade latency for not burning a core per process.

If the fix belongs in upstream Dawn's dawn/node AsyncRunner rather than this packaging repo, happy to have this forwarded / to file it there — reporting here first since this repo ships the binding as the webgpu npm package.

Environment

• webgpu 0.4.0 (npm), Node.js v22.x
• Linux x64, NVIDIA driver 595.x (RTX 4060 Ti, RTX 4090), Vulkan backend
• macOS (Apple M4), Metal backend

[kevinsproles]

Follow-up: I tracked this to root cause and have a patch, built with this repo's own recipe and validated on the same Linux/NVIDIA setup as the report — idle burn drops 1.120 → 0.039 cores with no measurable completion-latency regression under load. Sharing it here since the fix lands in Dawn's dawn/node bindings (which this repo builds pristine from the submodule), and Dawn takes changes via Gerrit (dawn-review.googlesource.com) rather than GitHub PRs — happy for anyone with a CLA on file to carry it there, or to submit it myself if that's the best path.

Root cause

Two pieces interact (paths in the Dawn submodule, at the pin c5d549e250b9 — both files are unchanged on current Dawn main, so this applies upstream too):

1. src/dawn/node/binding/AsyncRunner.cpp — ScheduleProcessEvents(): while tasks_waiting_ > 0, the runner schedules a setImmediate callback that calls wgpuInstanceProcessEvents() and immediately reschedules itself. setImmediate runs every event-loop turn, so this is a full-speed poll: the loop never blocks in epoll and the thread never sleeps.

2. src/dawn/node/binding/GPUAdapter.cpp:193-194 — requestDevice(): the binding allocates a DeviceLostContext (an AsyncContext) to back the GPUDevice.lost promise. AsyncContext's constructor calls AsyncRunner::Begin() (tasks_waiting_ → 1), and its matching End() only runs when the device-lost callback finally fires — i.e. at device.destroy() or a real loss.

So from the moment requestDevice() resolves there is always at least one "task in flight" (the permanently-pending device.lost future), and the pump spins the main JS thread at event-loop speed for the entire lifetime of the device, calling ProcessEvents millions of times with nothing to deliver. That matches every observed symptom: starts exactly at requestDevice, stops exactly at destroy(), shows up as processImmediate on the main thread, and the Linux-vs-macOS cost difference tracks the backend's per-call ProcessEvents cost.

Fix

AsyncRunner keeps polling, but adapts its rate to whether tasks are actually making progress (this is the TODO(crbug.com/dawn/1127) already in the file):

• Hot path unchanged: while any task has started (Begin()) or finished (End()) within the last 50ms, keep pumping with setImmediate exactly as today — completion latency under load is untouched.
• Idle fallback: once nothing has made progress for 50ms (e.g. the only pending future is device.lost), drop to a 4ms setTimeout poll (~250 wakeups/s instead of an unthrottled spin).
• Instant wake: Begin() (any new async task: mapAsync, onSubmittedWorkDone, pipeline creation, …) preempts a pending idle poll with a fresh setImmediate tick (a generation counter makes the superseded timer a no-op), so new work never waits for the slow timer.

Spontaneous events (device loss) are still delivered within ≤4ms via the idle poll. No API/behavior change otherwise; the pump still stops entirely when tasks_waiting_ == 0 and the loop-liveness semantics (what keeps the process alive) are unchanged.

Patch (applies to Dawn at c5d549e250b9 and rebases cleanly onto current main):

asyncrunner-idle-backoff.patch

diff --git a/src/dawn/node/binding/AsyncRunner.cpp b/src/dawn/node/binding/AsyncRunner.cpp
index 9c16028b5..4db4384b3 100644
--- a/src/dawn/node/binding/AsyncRunner.cpp
+++ b/src/dawn/node/binding/AsyncRunner.cpp
@@ -30,6 +30,21 @@
 #include <cassert>
 #include <limits>
 
+namespace {
+
+// While a task has started or finished within this period, ProcessEvents is pumped with
+// setImmediate() (i.e. polled every event loop turn) to deliver completions with minimal
+// latency. After this long without any task progress, the pump drops to a low-frequency
+// setTimeout() poll so that permanently-pending tasks (such as the one that holds
+// GPUDevice.lost open for the lifetime of the device) do not busy-spin the event loop.
+constexpr std::chrono::milliseconds kSpinGracePeriod{50};
+
+// Poll period once the pump has gone idle. Kept small so that spontaneous events (such as
+// device loss) and tasks that complete long after they start are still delivered promptly.
+constexpr uint32_t kIdlePollDelayMs = 4;
+
+}  // namespace
+
 namespace wgpu::binding {
 
 // static
@@ -43,45 +58,62 @@ AsyncRunner::AsyncRunner(dawn::native::Instance* instance) : instance_(instance)
 
 void AsyncRunner::Begin(Napi::Env env) {
     assert(tasks_waiting_ != std::numeric_limits<decltype(tasks_waiting_)>::max());
-    if (tasks_waiting_++ == 0) {
-        ScheduleProcessEvents(env);
+    tasks_waiting_++;
+    last_progress_ = std::chrono::steady_clock::now();
+    if (!process_events_queued_ || queued_delay_ms_ != 0) {
+        // Either nothing is queued, or only an idle poll is queued. Schedule an immediate
+        // tick so the new task's completion is polled for without delay; a superseded idle
+        // poll becomes a no-op via the generation check.
+        ScheduleProcessEvents(env, 0);
     }
 }
 
 void AsyncRunner::End() {
     assert(tasks_waiting_ > 0);
     tasks_waiting_--;
+    last_progress_ = std::chrono::steady_clock::now();
 }
 
-void AsyncRunner::ScheduleProcessEvents(Napi::Env env) {
-    // TODO(crbug.com/dawn/1127): We probably want to reduce the frequency at which this gets
-    // called.
-    if (process_events_queued_) {
-        return;
-    }
+void AsyncRunner::ScheduleProcessEvents(Napi::Env env, uint32_t delay_ms) {
     if (tasks_waiting_ == 0) {
         return;
     }
     process_events_queued_ = true;
+    queued_delay_ms_ = delay_ms;
+    const uint64_t generation = ++generation_;
 
     auto weak_self = weak_this_;
-    env.Global()
-        .Get("setImmediate")
-        .As<Napi::Function>()
-        .Call({
-            // TODO(crbug.com/dawn/1127): Create once, reuse.
-            Napi::Function::New(env,
-                                [weak_self, env](const Napi::CallbackInfo&) {
-                                    auto self = weak_self.lock();
-                                    if (self == nullptr) {
-                                        return;
-                                    }
-
-                                    self->process_events_queued_ = false;
-                                    wgpuInstanceProcessEvents(self->instance_->Get());
-                                    self->ScheduleProcessEvents(env);
-                                }),
-        });
+    // TODO(crbug.com/dawn/1127): Create once, reuse.
+    auto callback = Napi::Function::New(env, [weak_self, env, generation](const Napi::CallbackInfo&) {
+        auto self = weak_self.lock();
+        if (self == nullptr) {
+            return;
+        }
+        if (generation != self->generation_) {
+            // This callback was superseded by a later schedule (an idle poll preempted by
+            // Begin()); the newer callback owns the pump now.
+            return;
+        }
+
+        self->process_events_queued_ = false;
+        self->Tick(env);
+    });
+
+    if (delay_ms == 0) {
+        env.Global().Get("setImmediate").As<Napi::Function>().Call({callback});
+    } else {
+        env.Global().Get("setTimeout").As<Napi::Function>().Call(
+            {callback, Napi::Number::New(env, delay_ms)});
+    }
+}
+
+void AsyncRunner::Tick(Napi::Env env) {
+    wgpuInstanceProcessEvents(instance_->Get());
+    // Any task that completed during ProcessEvents() above has called End(), updating
+    // last_progress_.
+    const auto now = std::chrono::steady_clock::now();
+    const bool recently_active = (now - last_progress_) < kSpinGracePeriod;
+    ScheduleProcessEvents(env, recently_active ? 0 : kIdlePollDelayMs);
 }
 
 void AsyncRunner::Reject(Napi::Env env, interop::Promise<void> promise, Napi::Error error) {
diff --git a/src/dawn/node/binding/AsyncRunner.h b/src/dawn/node/binding/AsyncRunner.h
index f61660b01..e69f560f2 100644
--- a/src/dawn/node/binding/AsyncRunner.h
+++ b/src/dawn/node/binding/AsyncRunner.h
@@ -31,6 +31,7 @@
 #include <stdint.h>
 #include <webgpu/webgpu_cpp.h>
 
+#include <chrono>
 #include <memory>
 #include <utility>
 
@@ -68,12 +69,36 @@ class AsyncRunner {
     explicit AsyncRunner(dawn::native::Instance* instance);
 
   private:
-    void ScheduleProcessEvents(Napi::Env env);
+    // Schedules a call to Tick() on the main JavaScript thread. A `delay_ms` of 0 schedules
+    // with setImmediate() (runs every event loop turn), a non-zero delay schedules with
+    // setTimeout() (a low-frequency idle poll).
+    void ScheduleProcessEvents(Napi::Env env, uint32_t delay_ms);
+
+    // Calls wgpu::Instance::ProcessEvents() and re-schedules itself while there are
+    // asynchronous tasks in flight.
+    //
+    // Some tasks are pending for the entire lifetime of an object (for example the task that
+    // holds GPUDevice.lost open resolves only when the device is lost or destroyed), so
+    // `tasks_waiting_ > 0` does not imply that any task can currently make progress. To avoid
+    // spinning the event loop at full speed forever in that state, Tick() re-schedules itself
+    // with setImmediate() only while tasks have recently started or finished; once no task has
+    // made progress for kSpinGracePeriod it falls back to a low-frequency setTimeout() poll.
+    // Begin() switches the pump back to setImmediate() immediately, so completion latency for
+    // newly-started tasks is unaffected.
+    void Tick(Napi::Env env);
 
     std::weak_ptr<AsyncRunner> weak_this_;
     const dawn::native::Instance* const instance_;
     uint64_t tasks_waiting_ = 0;
     bool process_events_queued_ = false;
+    // Delay used to schedule the currently-queued Tick(), if any. Non-zero means the queued
+    // tick is an idle poll that Begin() should preempt with an immediate tick.
+    uint32_t queued_delay_ms_ = 0;
+    // Incremented on every schedule; a queued callback whose generation no longer matches has
+    // been superseded (e.g. an idle poll preempted by Begin()) and does nothing.
+    uint64_t generation_ = 0;
+    // The last time a task was started (Begin()) or finished (End()).
+    std::chrono::steady_clock::time_point last_progress_ = std::chrono::steady_clock::now();
 };
 
 // AsyncTask is a RAII helper for calling AsyncRunner::Begin() on construction, and

Validation

Built linux-x64.dawn.node with this repo's own recipe (npm ci && npm run build, Dawn submodule at the pin, only the patch above applied). Node v22, Linux x64, NVIDIA RTX 4060 Ti (driver 595.71), Vulkan backend, 16-core host.

Idle burn (the repro from the issue, 8s per stage):

stage	stock webgpu@0.4.0	patched
after requestDevice() (idle)	1.120 cores	0.039 cores
after one empty submit (idle)	1.118 cores	0.040 cores
after device.destroy()	0.000 cores	0.000 cores

Async completion latency (500-iteration tight loops; 256KiB copy + mapAsync(READ) round-trip, and empty-submit + onSubmittedWorkDone):

metric	stock	patched
tight mapAsync round-trip mean / p50 / p95	0.071 / 0.066 / 0.075 ms	0.066 / 0.062 / 0.071 ms
tight onSubmittedWorkDone mean / p50 / p95	0.038 / 0.034 / 0.042 ms	0.040 / 0.036 / 0.043 ms
mapAsync round-trip after 200ms of idle (worst case for the idle poll), mean / p95	2.401 / 3.466 ms	1.526 / 4.279 ms

A 64K-element compute dispatch (y = 2x + 1) verifies output correctness with the patched binary: PASS (all 65536 elements correct).

The two tunables (kSpinGracePeriod = 50ms, kIdlePollDelayMs = 4ms) are deliberately conservative; the worst-case cost is ≤4ms extra latency for a completion that arrives >50ms after the last task activity. If maintainers prefer, the same structure supports an exponential ramp instead of a flat idle rate, but flat seemed easier to reason about.

[greggman]

This is great! That said, like is mentions in the readme, this is just a repo that builds the plugin that exists upstream. If you have time to try to submit it upstream that would be great! I don’t know when I would be able to find the time.

https://dawn.googlesource.com/dawn/

[greggman]

I put up a CL

https://dawn-review.googlesource.com/c/dawn/+/337815