Re: NFSv4 performance degradation with 12.0-CURRENT client

On Sat, Nov 26, 2016 at 11:19:19PM +0000, Rick Macklem wrote:
> Konstantin Belousov wrote:
> [stuff snipped]
> >I thought that the issue was in tracking any opens and mmaps, but from this
> >reply it is not that clear.  Do you need callback when all opens and mmaps
> >have ended, or only opens and mmaps for write ?  If later, we already have
> >a suitable mechanism VOP_ADD_WRITECOUNT().
> 
> Not quite. The NFSv4 client needs to Close the NFSv4 Open after all I/O on
> the file has been done. This applies to both reads and writes.
> Since mmap'd files can generate I/O after the VOP_CLOSE(), the NFSv4 client
> can't do the NFSv4 Close in VOP_CLOSE().
> Since it can't do it then, it waits until VOP_INACTIVE() to do the NFSv4 Close.
> 
> This might be improved by:
> - A flag that indicates that an open file descriptor has been mmap()d, which
>   VOP_CLOSE() could check to decide if it can do the NFSv4 Close.
>   (ie. It could do the NFSv4 Close if the file descriptor hasn't been mmap()d.)
> - If the system knows when mmap()d I/O is done (the process has terminated?),
>   it could do a VOP_MMAP_IO_DONE() and the NFSv4 client would do the NFSv4 Close
>   in it.
>   --> I don't know if this is feasible and I suspect if it could be done, that it would
>         usually happen just before VOP_INACTIVE(). { This case of nullfs caching was an
>         exception, I think? }
> 
> Does this clarify it? rick

Thank you, yes, it clarifies the things, and makes it clear that my idea
is not feasible.

It is not hard to count number of mappings for the vnode object, but I
do not want to do this by straight-forward addition of the counter to
the vnode or vm object, since that would significantly increase amount
of memory used by VFS.