News › performance
By The Linux Camp News, October 18, 2026
A draft libkrun proposal processes filesystem requests in the notifying vCPU thread, avoiding worker handoffs and completion interrupts. It requires guest cooperation, rather than enabling gains for every VirtIO-FS VM.
Sergio López presented experimental synchronous queues for VirtIO-FS in libkrun pull request #933 on October 16, 2026. The proposal remained a two-commit draft in the October 18 source snapshot, not a released upgrade. Its scope is guest-to-host filesystem sharing: it changes how cooperating virtual machines submit and complete filesystem requests. 2 3 1
The usual VirtIO path is asynchronous. A virtual CPU places a request in a virtqueue, the request-and-response queue, and notifies the host through a brief VM exit. The guest can then do other work while the host processes the request; a completion interrupt tells it when the reply is ready. That separation is less useful when the workload cannot proceed until a filesystem operation finishes: it still pays for the worker handoff and interrupt. 2 3 1
Negotiating the experimental VIRTIO_FS_F_SYNC feature instead creates one synchronous queue per configured vCPU. During the notification's VM exit, the host thread running that vCPU executes the filesystem request itself. It publishes the response before returning to the guest, which finds its reply without a completion interrupt. The optimization removes intermediate scheduling and notification steps, rather than making the underlying storage faster. 2 3
The second commit addresses a bottleneck within that new path. Holding shared bus and filesystem device locks during request processing would serialize the per-vCPU queues, letting one slow host operation block unrelated notifications. The revision selects a handler under those locks, releases them before execution, and gives each queue its own mutex. Separate queues therefore need not wait behind a shared lock for the whole filesystem operation. 4 2
López reports that building libkrunfw fell from 7m43.826s with normal queues to 5m34.348s with synchronous queues. Calculated from those elapsed times, that is about 28% less waiting for the build. His description of approximately 38% faster expresses the reciprocal speed increase, not a 38% reduction in elapsed time. These are the proposal author's measurements, not independent validation, but they give build-workflow operators a concrete workload to evaluate. 2
For an evaluation, check both sides of the interface: the experimental libkrun implementation and a guest capable of negotiating the feature are required. López points to a separate Linux support branch. Guests that do not negotiate it retain the original worker path, so installing host-side changes alone is not evidence that a VM is exercising synchronous queues. The practical prerequisite is feature negotiation, not merely the presence of VirtIO-FS. 2 3 4
The reported build used eight vCPUs on an M3 Pro, but the description gives VM memory as “8192 GB.” That allocation needs clarification rather than silent correction. The result does not establish equivalent gains on other hardware or workloads. As of the October 18 snapshot, draft status also leaves release availability unresolved; this is an experimental comparison, not a package-version recommendation. 2 3