NFSv4 performance degradation with 12.0-CURRENT client

[Rick Macklem]

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