All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH RFC] NFSD: synchronously unhash a file on NFSv4 CLOSE
@ 2020-09-10 19:45 Chuck Lever
  2020-09-14 20:51 ` J. Bruce Fields
  0 siblings, 1 reply; 4+ messages in thread
From: Chuck Lever @ 2020-09-10 19:45 UTC (permalink / raw)
  To: bfields, trond.myklebust, jlayton; +Cc: linux-nfs

I recently observed a significant slowdown in a long-running
test on NFSv4.0 mounts.

An OPEN for write seems to block the NFS server from offering
delegations on that file for a few seconds. The problem is that
when that file is closed, the filecache retains an open-for-write
file descriptor until the laundrette runs. That keeps the inode's
i_writecount positive until the cached file is finally unhashed
and closed.

Force the NFSv4 CLOSE logic to call filp_close() to eliminate
the underlying cached open-for-write file as soon as the client
closes the file.

This minor change claws back about 80% of the performance
regression.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
 fs/nfsd/nfs4state.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 3ac40ba7efe1..0b3059b8b36c 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -613,10 +613,14 @@ static void __nfs4_file_put_access(struct nfs4_file *fp, int oflag)
 		if (atomic_read(&fp->fi_access[1 - oflag]) == 0)
 			swap(f2, fp->fi_fds[O_RDWR]);
 		spin_unlock(&fp->fi_lock);
-		if (f1)
+		if (f1) {
+			nfsd_file_close_inode_sync(locks_inode(f1->nf_file));
 			nfsd_file_put(f1);
-		if (f2)
+		}
+		if (f2) {
+			nfsd_file_close_inode_sync(locks_inode(f2->nf_file));
 			nfsd_file_put(f2);
+		}
 	}
 }
 



^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] NFSD: synchronously unhash a file on NFSv4 CLOSE
  2020-09-10 19:45 [PATCH RFC] NFSD: synchronously unhash a file on NFSv4 CLOSE Chuck Lever
@ 2020-09-14 20:51 ` J. Bruce Fields
  2020-09-14 20:53   ` Chuck Lever
  0 siblings, 1 reply; 4+ messages in thread
From: J. Bruce Fields @ 2020-09-14 20:51 UTC (permalink / raw)
  To: Chuck Lever; +Cc: trond.myklebust, jlayton, linux-nfs

On Thu, Sep 10, 2020 at 03:45:12PM -0400, Chuck Lever wrote:
> I recently observed a significant slowdown in a long-running
> test on NFSv4.0 mounts.
> 
> An OPEN for write seems to block the NFS server from offering
> delegations on that file for a few seconds. The problem is that
> when that file is closed, the filecache retains an open-for-write
> file descriptor until the laundrette runs. That keeps the inode's
> i_writecount positive until the cached file is finally unhashed
> and closed.
> 
> Force the NFSv4 CLOSE logic to call filp_close() to eliminate
> the underlying cached open-for-write file as soon as the client
> closes the file.
> 
> This minor change claws back about 80% of the performance
> regression.

That's really useful to know.  But mainly this makes me think that
nfsd4_check_conflicting_opens() is wrong.

I'm trying to determine whether a given file has a non-nfsd writer by
counting the number of write opens nfsd holds on a given file and
subtracting that from i_writecount.

But the way I'm counting write opens probably isn't correct.

--b.

> 
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
>  fs/nfsd/nfs4state.c |    8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index 3ac40ba7efe1..0b3059b8b36c 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -613,10 +613,14 @@ static void __nfs4_file_put_access(struct nfs4_file *fp, int oflag)
>  		if (atomic_read(&fp->fi_access[1 - oflag]) == 0)
>  			swap(f2, fp->fi_fds[O_RDWR]);
>  		spin_unlock(&fp->fi_lock);
> -		if (f1)
> +		if (f1) {
> +			nfsd_file_close_inode_sync(locks_inode(f1->nf_file));
>  			nfsd_file_put(f1);
> -		if (f2)
> +		}
> +		if (f2) {
> +			nfsd_file_close_inode_sync(locks_inode(f2->nf_file));
>  			nfsd_file_put(f2);
> +		}
>  	}
>  }
>  
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] NFSD: synchronously unhash a file on NFSv4 CLOSE
  2020-09-14 20:51 ` J. Bruce Fields
@ 2020-09-14 20:53   ` Chuck Lever
  2020-09-15 13:18     ` Chuck Lever
  0 siblings, 1 reply; 4+ messages in thread
From: Chuck Lever @ 2020-09-14 20:53 UTC (permalink / raw)
  To: Bruce Fields; +Cc: Trond Myklebust, Jeff Layton, Linux NFS Mailing List



> On Sep 14, 2020, at 4:51 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> 
> On Thu, Sep 10, 2020 at 03:45:12PM -0400, Chuck Lever wrote:
>> I recently observed a significant slowdown in a long-running
>> test on NFSv4.0 mounts.
>> 
>> An OPEN for write seems to block the NFS server from offering
>> delegations on that file for a few seconds. The problem is that
>> when that file is closed, the filecache retains an open-for-write
>> file descriptor until the laundrette runs. That keeps the inode's
>> i_writecount positive until the cached file is finally unhashed
>> and closed.
>> 
>> Force the NFSv4 CLOSE logic to call filp_close() to eliminate
>> the underlying cached open-for-write file as soon as the client
>> closes the file.
>> 
>> This minor change claws back about 80% of the performance
>> regression.
> 
> That's really useful to know.  But mainly this makes me think that
> nfsd4_check_conflicting_opens() is wrong.
> 
> I'm trying to determine whether a given file has a non-nfsd writer by
> counting the number of write opens nfsd holds on a given file and
> subtracting that from i_writecount.
> 
> But the way I'm counting write opens probably isn't correct.

I entertained that possibility, but I couldn't figure out
a better way to count opens-for-write.


> --b.
> 
>> 
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>> fs/nfsd/nfs4state.c |    8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>> 
>> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
>> index 3ac40ba7efe1..0b3059b8b36c 100644
>> --- a/fs/nfsd/nfs4state.c
>> +++ b/fs/nfsd/nfs4state.c
>> @@ -613,10 +613,14 @@ static void __nfs4_file_put_access(struct nfs4_file *fp, int oflag)
>> 		if (atomic_read(&fp->fi_access[1 - oflag]) == 0)
>> 			swap(f2, fp->fi_fds[O_RDWR]);
>> 		spin_unlock(&fp->fi_lock);
>> -		if (f1)
>> +		if (f1) {
>> +			nfsd_file_close_inode_sync(locks_inode(f1->nf_file));
>> 			nfsd_file_put(f1);
>> -		if (f2)
>> +		}
>> +		if (f2) {
>> +			nfsd_file_close_inode_sync(locks_inode(f2->nf_file));
>> 			nfsd_file_put(f2);
>> +		}
>> 	}
>> }

--
Chuck Lever




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] NFSD: synchronously unhash a file on NFSv4 CLOSE
  2020-09-14 20:53   ` Chuck Lever
@ 2020-09-15 13:18     ` Chuck Lever
  0 siblings, 0 replies; 4+ messages in thread
From: Chuck Lever @ 2020-09-15 13:18 UTC (permalink / raw)
  To: Bruce Fields; +Cc: Trond Myklebust, Jeff Layton, Linux NFS Mailing List



> On Sep 14, 2020, at 4:53 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
> 
> 
> 
>> On Sep 14, 2020, at 4:51 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>> 
>> On Thu, Sep 10, 2020 at 03:45:12PM -0400, Chuck Lever wrote:
>>> I recently observed a significant slowdown in a long-running
>>> test on NFSv4.0 mounts.
>>> 
>>> An OPEN for write seems to block the NFS server from offering
>>> delegations on that file for a few seconds. The problem is that
>>> when that file is closed, the filecache retains an open-for-write
>>> file descriptor until the laundrette runs. That keeps the inode's
>>> i_writecount positive until the cached file is finally unhashed
>>> and closed.
>>> 
>>> Force the NFSv4 CLOSE logic to call filp_close() to eliminate
>>> the underlying cached open-for-write file as soon as the client
>>> closes the file.
>>> 
>>> This minor change claws back about 80% of the performance
>>> regression.
>> 
>> That's really useful to know.  But mainly this makes me think that
>> nfsd4_check_conflicting_opens() is wrong.
>> 
>> I'm trying to determine whether a given file has a non-nfsd writer by
>> counting the number of write opens nfsd holds on a given file and
>> subtracting that from i_writecount.
>> 
>> But the way I'm counting write opens probably isn't correct.
> 
> I entertained that possibility, but I couldn't figure out
> a better way to count opens-for-write.

Also, the regression started long before nfsd4_check_conflicting_opens
was added.


>> --b.
>> 
>>> 
>>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>>> ---
>>> fs/nfsd/nfs4state.c |    8 ++++++--
>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
>>> index 3ac40ba7efe1..0b3059b8b36c 100644
>>> --- a/fs/nfsd/nfs4state.c
>>> +++ b/fs/nfsd/nfs4state.c
>>> @@ -613,10 +613,14 @@ static void __nfs4_file_put_access(struct nfs4_file *fp, int oflag)
>>> 		if (atomic_read(&fp->fi_access[1 - oflag]) == 0)
>>> 			swap(f2, fp->fi_fds[O_RDWR]);
>>> 		spin_unlock(&fp->fi_lock);
>>> -		if (f1)
>>> +		if (f1) {
>>> +			nfsd_file_close_inode_sync(locks_inode(f1->nf_file));
>>> 			nfsd_file_put(f1);
>>> -		if (f2)
>>> +		}
>>> +		if (f2) {
>>> +			nfsd_file_close_inode_sync(locks_inode(f2->nf_file));
>>> 			nfsd_file_put(f2);
>>> +		}
>>> 	}
>>> }
> 
> --
> Chuck Lever

--
Chuck Lever




^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-09-15 18:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-10 19:45 [PATCH RFC] NFSD: synchronously unhash a file on NFSv4 CLOSE Chuck Lever
2020-09-14 20:51 ` J. Bruce Fields
2020-09-14 20:53   ` Chuck Lever
2020-09-15 13:18     ` Chuck Lever

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.