]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commit
crimson/os/seastore: yield to user IO between cleaner cycles 68961/head
authorShai Fultheim <shai.fultheim@gmail.com>
Sun, 17 May 2026 08:27:00 +0000 (11:27 +0300)
committerShai Fultheim <shai.fultheim@gmail.com>
Mon, 18 May 2026 13:28:58 +0000 (16:28 +0300)
commit06800d9655de625c7eb2eaaffdd5cc5427cd0aea
tree2119cf02780df6e9c2db947cdfa6d782bd28fcce
parentc53bacdbcc2988efb027350d0f35c71c98749167
crimson/os/seastore: yield to user IO between cleaner cycles

After the deadlock fix in the preceding commit ("fix IO-block deadlock
when cleaner is sleeping"), the cleaner stays awake while user IO is
blocked, but a second symptom appears at high alive_ratio (~0.79): the
cleaner's segment-allocate-and-fill loop runs tightly enough that the
user-IO continuation scheduled by maybe_wake_blocked_io() never gets a
chance to retry try_reserve_io() before the cleaner consumes the
projected_avail headroom again on its next iteration. User IO wakes,
sees projected_avail still below hard_limit, re-blocks immediately.

In the qa/standalone/crimson randwrite bench this manifests as: cluster
makes 500-700 GB of progress, then user_written counter freezes for
~75 seconds (watchdog window) while the cleaner is fully busy.

In BackgroundProcess::run(), after each do_background_cycle, if user IO
is currently blocked, yield to the reactor. That gives the woken
user-IO continuation a chance to slot in and complete a reservation
before the cleaner starts its next reservation-consuming cycle.

With this change, the same bench runs 19 minutes (vs 11-16 min) and
writes 785 GB user (vs 506-692 GB) before the next cluster limit hits,
which is the inherent throughput cap at alive_ratio 0.79 where each
reclaim only frees ~21% of segment size — not a coordination bug.

Signed-off-by: Shai Fultheim <shai.fultheim@gmail.com>
src/crimson/os/seastore/extent_placement_manager.cc
src/crimson/os/seastore/extent_placement_manager.h