From owner-freebsd-current@freebsd.org Sun Nov 27 14:06:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECC53C55E08 for ; Sun, 27 Nov 2016 14:06:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81894931; Sun, 27 Nov 2016 14:06:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uARE6kf5082876 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 27 Nov 2016 16:06:47 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uARE6kf5082876 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uARE6k4l082875; Sun, 27 Nov 2016 16:06:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 27 Nov 2016 16:06:46 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Alan Somers , FreeBSD CURRENT Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client Message-ID: <20161127140646.GL54029@kib.kiev.ua> References: <20161124090811.GO54029@kib.kiev.ua> <20161125084106.GX54029@kib.kiev.ua> <20161125135725.GD54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 14:06:54 -0000 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.