From 32e7978a6ec5d5f6f397b59738a75ae7cc534231 Mon Sep 17 00:00:00 2001 From: Zach Brown Date: Mon, 25 Jan 2021 09:50:13 -0800 Subject: [PATCH] Extend lock invalidate grace period The grace period is intended to let lock holders squeeze in more bulk work before another node pulls the lock out from under them. The length of the delay is a balance between getting more work done per lock hold and adding latency to ping-ponging workloads. The current grace period was too short. To do work in the conflicting case you often have to read the result that the other mount wrote as you invalidated their lock. The test was written in the LSM world where we'd effectively read a single level 0 1MB segment. In the btree world we're checking bloom blocks and reading the other mount's btree. It has more dependent read latency. So we turn up the grace period to let conflicting readers squeeze in more work before pulling the lock out from under them. This value was chosen to make lock-conflicting-batch-commit pass in guests sharing nvme metadata devices in debugging kernels. Signed-off-by: Zach Brown --- kmod/src/lock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kmod/src/lock.c b/kmod/src/lock.c index 6ab4081c..189af768 100644 --- a/kmod/src/lock.c +++ b/kmod/src/lock.c @@ -65,7 +65,7 @@ * relative to that lock state we resend. */ -#define GRACE_PERIOD_KT ms_to_ktime(2) +#define GRACE_PERIOD_KT ms_to_ktime(10) /* * allocated per-super, freed on unmount.