Hi Pankaj ---- On Thu, 25 Jun 2026 01:22:14 +0800 Pankaj Gupta <[email protected]> wrote --- > > pmem_submit_bio() passes the parent bio to nvdimm_flush() for > > REQ_FUA. For virtio-pmem this makes async_pmem_flush() allocate > > and submit a child PREFLUSH bio chained to the parent. > > > > That child allocation is in the block submit path. Making it > > blocking with GFP_NOIO can consume the same global bio mempool that > > submit_bio() uses, while making it GFP_ATOMIC can fail under > > pressure. A forced failure of the child allocation produced: > > > > virtio_pmem: forcing child bio allocation failure for test > > Buffer I/O error on dev pmem0, logical block 0, lost sync page write > > EXT4-fs (pmem0): I/O error while writing superblock > > EXT4-fs (pmem0): mount failed > > > > Avoid the child bio completely. Flush FUA synchronously, like > > REQ_PREFLUSH, then complete the parent after the flush. Since no > > child bio can be created, async_pmem_flush() now only issues the > > virtio flush and preserves negative errno values. > > Child flush is asynchronous (performs async flush to host side and returns). > Till child bio completes guest userspace waits in pending IO state. > It seems the current change will affect the behavior? > > Prior RFC [1] attempted to coalesce the async FLUSH request between guest > &host. > If there is interest, that approach could be revisited or integrated here? > > [1] > https://lore.kernel.org/all/[email protected]/#t
Yes, agreed. This does change the FUA path. I will rework it to avoid the child bio allocation while keeping the parent bio completion asynchronous, using your RFC as reference. Regards, Li
