Skip to content

perf: optimize virtio-blk queue size and memory barrier#249

Open
cg24-THU wants to merge 1 commit into
rcore-os:masterfrom
cg24-THU:perf/optimize-queue-size-and-memory-barrier
Open

perf: optimize virtio-blk queue size and memory barrier#249
cg24-THU wants to merge 1 commit into
rcore-os:masterfrom
cg24-THU:perf/optimize-queue-size-and-memory-barrier

Conversation

@cg24-THU

Copy link
Copy Markdown

Two performance improvements for the virtio-blk driver.

  1. Queue size 16 to 256: matches Linux virtio_blk default, reduces per-request notification overhead.
  2. Memory barrier SeqCst to Release: matches Linux dma_wmb semantics. On RISC-V changes fence rw,rw to fence rw,w.

Benchmark on StarryOS riscv64 QEMU TCG 10MB sequential IO:
READ 4K: 35.74 to 42.09 MB/s (+17.8%)
WRITE 4K: 1.11 to 1.15 MB/s (+3.6%)

Test plan: cargo check passes, StarryOS smoke test no regression.

- Increase default virtio-blk queue size from 16 to 256, matching the
  Linux virtio_blk default. A larger queue allows more in-flight
  requests and reduces per-request notification overhead.

- Relax the memory barrier in VirtQueue::add() from SeqCst to Release.
  The fence only needs to order descriptor table and available ring
  writes before the available index store. A Release fence is
  sufficient for this producer-ordering requirement, matching Linux's
  dma_wmb()/virtio_wmb() semantics. On RISC-V this changes the
  instruction from `fence rw,rw` to `fence rw,w`.

Measured on StarryOS (riscv64, QEMU TCG, 10MB sequential I/O):
  READ  4K: 35.74 → 42.09 MB/s (+17.8%)
  WRITE 4K: 1.11 → 1.15 MB/s  (+3.6%)
@qwandor

qwandor commented May 27, 2026

Copy link
Copy Markdown
Collaborator

Are you using write_blocks_nb / read_blocks_nb? And do you know how much of the performance increase comes from the queue size change versus the memory barrier change? Making the queue 16 times bigger seems like a big change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants