Re: [PATCH v8 0/8] nbd: eliminate queue freeze/unfreeze overhead in connection setup

Hi Yang, Kuai, Jens,

I'm writing as another production user of exactly the workload this
series targets. We run AI sandboxes on Firecracker microVMs whose
rootfs is attached over NBD, and we launch many microVMs concurrently
on many-core hosts. We independently traced the same problem this
series fixes: the blk_mq_freeze_queue() calls on the connect path each
wait a full RCU grace period (~35-50ms on our many-core hosts), and
because many connects run concurrently at VM-create time these stack up
into a significant create tail-latency contributor. So this is a real,
independently-hit problem on our side, not a synthetic one -- thanks
for working on it.

FWIW I had separately narrowed it down to the same two spots (the
nbd_add_socket() freeze from b98e762e3d71 and the nbd_set_size() freeze
from 242a49e5c878) and was about to ask the list whether the add_socket
freeze could be conditionalized on the initial connect. Your approach
is cleaner: patch 2 removing the freeze's root cause by rejecting
NBD_SET_SOCK on an active device -- rather than relying on the
capacity==0 / bio_check_eod invariant to keep holding -- is exactly the
right way to make patch 4 safe, and patches 7-8 also cover the
blk_mq_update_nr_hw_queues() freeze in nbd_start_device() that I had
not addressed.

The whole direction has my strong support. If it's useful, I'm happy to
apply the series on our Firecracker + many-core setup and follow up with
a Tested-by and our create-latency numbers -- just let me know whether
that would help before it's applied.

Jens, as a second, independent production site hitting this: we'd
really like to see this land.

Thanks,
Zhichao Huang <[email protected]>