From owner-freebsd-fs@freebsd.org Thu Nov 5 20:53:01 2015 Return-Path: Delivered-To: freebsd-fs@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 E04F7A27F55 for ; Thu, 5 Nov 2015 20:53:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C4FED1246 for ; Thu, 5 Nov 2015 20:53:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C33C0A27F54; Thu, 5 Nov 2015 20:53:00 +0000 (UTC) Delivered-To: fs@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 C2D3FA27F52 for ; Thu, 5 Nov 2015 20:53:00 +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 3D9421243 for ; Thu, 5 Nov 2015 20:53:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tA5KqtHJ014920 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 5 Nov 2015 22:52:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tA5KqtHJ014920 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tA5Kqt2m014919; Thu, 5 Nov 2015 22:52:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Nov 2015 22:52:55 +0200 From: Konstantin Belousov To: Kirk McKusick Cc: fs@freebsd.org Subject: Re: an easy (?) question on namecache sizing Message-ID: <20151105205255.GL2257@kib.kiev.ua> References: <20151105195648.GK2257@kib.kiev.ua> <201511052025.tA5KPcLF066724@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201511052025.tA5KPcLF066724@chez.mckusick.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 20:53:01 -0000 On Thu, Nov 05, 2015 at 12:25:38PM -0800, Kirk McKusick wrote: > > Date: Thu, 5 Nov 2015 21:56:48 +0200 > > From: Konstantin Belousov > > To: Kirk McKusick > > Subject: Re: an easy (?) question on namecache sizing > > Cc: fs@freebsd.org > > > > On Thu, Nov 05, 2015 at 10:56:55AM -0800, Kirk McKusick wrote: > >> > >> I propose that we update wantfreevnodes in sysctl_update_desiredvnodes() > >> so that it tracks the change in desiredvnodes: > >> > >> Index: /sys/kern/vfs_subr.c > >> =================================================================== > >> --- /sys/kern/vfs_subr.c (revision 290387) > >> +++ /sys/kern/vfs_subr.c (working copy) > >> @@ -293,6 +293,7 @@ > >> if (old_desiredvnodes != desiredvnodes) { > >> + wantfreevnodes = desiredvnodes / 4; > >> vfs_hash_changesize(desiredvnodes); > >> cache_changesize(desiredvnodes); > >> } > >> return (0); > >> } > >> > >> Otherwise bumping up desiredvnodes will be less effective than expected. > >> > >> I see that Bruce has also suggested this change in his more extensive > >> revisions. > > > > I think the idea is right, but the implementation is not. Just changing > > wantfreevnodes after desirevnodes was reduced, creates a window where an > > other thread could see small value for desiredvnodes, but large value > > for wantfreevnodes. Then, e.g. vlrureclaim() would go wild. IMO it should > > ensure that the observable values are non-contradictory. > > Does moving the setting of wantfreevnodes before the cache size changes > (as redone above) close the window enough? The vlrureclaim() function > operates slowly enough that a brief period of inconsistency seems > unimportant. Changing desiredvnodes happens very rarely. And at the moment > we are not correcting wantfreevnodes at all. Or am I missing some key point? I think wantfreevnodes should be set before the cache size changes when desiredvnodes is decreased, but kept at the place in your patch for the increasing case.