Parallel file locking quite slow with vers=4.0 compared to vers=3

Commit Message

J. Bruce Fields July 21, 2015, 3:51 p.m. UTC

On Tue, Jul 21, 2015 at 08:44:44AM +0200, Frank Steiner wrote:
> J. Bruce Fields wrote
> 
> > One way to confirm that might be to run client kernels modified to make
> > the polling behavior (controlled by
> > fs/nfs/nfs4proc.c:nfs4_set_lock_task_retry()) more aggressive, and see
> > if that removes the delays in your case.
> > 
> > If that works, then it might also be worth considering implementing
> > CB_NOTIFY_LOCK:
> > 
> > 	https://tools.ietf.org/html/rfc5661#page-593
> 
> I wouldn't mind to test any kind of patch if someone would find the time
> to provide some. Writing them myself is beyond my skills I'm afraid :-)

Well, I was just thinking of something like this.

(*Not* saying this is what we really want to do, but it might help
confirm where your delay is coming from.)

--b.

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Frank Steiner July 22, 2015, 2:49 p.m. UTC | #1

J. Bruce Fields wrote
o provide some. Writing them myself is beyond my skills I'm afraid :-)
> 
> Well, I was just thinking of something like this.
> 
> (*Not* saying this is what we really want to do, but it might help
> confirm where your delay is coming from.)

Thanks! I tried your patch and it goes way faster. The last 2 or 3
of 20 xterms that I start in parallel still take about 1-3 seconds,
but the rest is poping up immediately. NFS3 is still better as it
shows all xterm (almost) immediately, but the patch definitely is 
an improvement.

cu,
Frank

Frank Steiner July 22, 2015, 2:53 p.m. UTC | #2

Frank Steiner wrote

> Thanks! I tried your patch and it goes way faster. The last 2 or 3
> of 20 xterms that I start in parallel still take about 1-3 seconds,
> but the rest is poping up immediately. NFS3 is still better as it

The difference is still quite large when killing the xterms again. 
"killall xterm" on NFSv3 takes half a second, on NFSv4 the last
about 5 xterms are delayed and vanish one after another, the last one
about 5-6 seconds after the killall was started.

cu,
Frank

J. Bruce Fields July 22, 2015, 3:40 p.m. UTC | #3

On Wed, Jul 22, 2015 at 04:53:11PM +0200, Frank Steiner wrote:
> Frank Steiner wrote
> 
> > Thanks! I tried your patch and it goes way faster. The last 2 or 3
> > of 20 xterms that I start in parallel still take about 1-3 seconds,
> > but the rest is poping up immediately. NFS3 is still better as it
> 
> The difference is still quite large when killing the xterms again. 
> "killall xterm" on NFSv3 takes half a second, on NFSv4 the last
> about 5 xterms are delayed and vanish one after another, the last one
> about 5-6 seconds after the killall was started.

No idea what's going on there.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 6f228b5..c119ba7 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -5367,7 +5367,7 @@  int nfs4_proc_delegreturn(struct inode *inode, struct rpc_cred *cred, const nfs4
 	return err;
 }
 
-#define NFS4_LOCK_MINTIMEOUT (1 * HZ)
+#define NFS4_LOCK_MINTIMEOUT (1 * HZ / 10)
 #define NFS4_LOCK_MAXTIMEOUT (30 * HZ)
 
 /*