summaryrefslogtreecommitdiffstats
path: root/crypto/testmgr.c
diff options
context:
space:
mode:
authorLars Ellenberg <lars.ellenberg@linbit.com>2014-05-07 22:41:28 +0200
committerPhilipp Reisner <philipp.reisner@linbit.com>2014-07-10 18:35:21 +0200
commitf5b90b6bf0cf29a85ceaa8ce334b17814cd5d39b (patch)
treed10cc5f07027af4640fe9fe151f6e20c8edd3f84 /crypto/testmgr.c
parentcc356f85bb57a3587e4b1d944e669fe39b37cdf2 (diff)
downloadlinux-f5b90b6bf0cf29a85ceaa8ce334b17814cd5d39b.tar.gz
linux-f5b90b6bf0cf29a85ceaa8ce334b17814cd5d39b.tar.bz2
linux-f5b90b6bf0cf29a85ceaa8ce334b17814cd5d39b.zip
drbd: resync should only lock out specific ranges
During resync, if we need to block some specific incoming write because of active resync requests to that same range, we potentially caused *all* new application writes (to "cold" activity log extents) to block until this one request has been processed. Improve the do_submit() logic to * grab all incoming requests to some "incoming" list * process this list - move aside requests that are blocked by resync - prepare activity log transactions, - commit transactions and submit corresponding requests - if there are remaining requests that only wait for activity log extents to become free, stop the fast path (mark activity log as "starving") - iterate until no more requests are waiting for the activity log, but all potentially remaining requests are only blocked by resync * only then grab new incoming requests That way, very busy IO on currently "hot" activity log extents cannot starve scattered IO to "cold" extents. And blocked-by-resync requests are processed once resync traffic on the affected region has ceased, without blocking anything else. The only blocking mode left is when we cannot start requests to "cold" extents because all currently "hot" extents are actually used. Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Diffstat (limited to 'crypto/testmgr.c')
0 files changed, 0 insertions, 0 deletions