HomeFreeBSD

Speed up WB_SYNC_NONE when a WB_SYNC_ALL occurs simultaneously

Description

Speed up WB_SYNC_NONE when a WB_SYNC_ALL occurs simultaneously

Page writebacks with WB_SYNC_NONE can take several seconds to complete
since they wait for the transaction group to close before being
committed. This is usually not a problem since the caller does not
need to wait. However, if we're simultaneously doing a writeback
with WB_SYNC_ALL (e.g via msync), the latter can block for several
seconds (up to zfs_txg_timeout) due to the active WB_SYNC_NONE
writeback since it needs to wait for the transaction to complete
and the PG_writeback bit to be cleared.

This commit deals with 2 cases:

  • No page writeback is active. A WB_SYNC_ALL page writeback starts and even completes. But when it's about to check if the PG_writeback bit has been cleared, another writeback with WB_SYNC_NONE starts. The sync page writeback ends up waiting for the non-sync page writeback to complete.
  • A page writeback with WB_SYNC_NONE is already active when a WB_SYNC_ALL writeback starts. The WB_SYNC_ALL writeback ends up waiting for the WB_SYNC_NONE writeback.

The fix works by carefully keeping track of active sync/non-sync
writebacks and committing when beneficial.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Shaan Nobee <sniper111@gmail.com>
Closes #12662
Closes #12790

Details

Provenance
Shaan Nobee <sniper111@gmail.com>Authored on May 3 2022, 8:23 PM
Tony Hutter <hutter2@llnl.gov>Committed on Jun 5 2023, 5:59 PM
Parents
rG8a315a30ab45: ZIL: Allow to replay blocks of any size.
Branches
Unknown
Tags
Unknown

Event Timeline

Tony Hutter <hutter2@llnl.gov> committed rG9e5a297de66b: Speed up WB_SYNC_NONE when a WB_SYNC_ALL occurs simultaneously (authored by Shaan Nobee <sniper111@gmail.com>).Jun 5 2023, 5:59 PM