From owner-svn-src-head@FreeBSD.ORG Sat Jun 15 10:43:10 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 49D06DBC; Sat, 15 Jun 2013 10:43:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B246B1139; Sat, 15 Jun 2013 10:43:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r5FAh3rv090307; Sat, 15 Jun 2013 13:43:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5FAh3rv090307 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5FAh1Mk090306; Sat, 15 Jun 2013 13:43:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 15 Jun 2013 13:43:01 +0300 From: Konstantin Belousov To: Bruce Evans Subject: Re: svn commit: r251282 - head/sys/kern Message-ID: <20130615104301.GL91021@kib.kiev.ua> References: <201306030416.r534GmCA001872@svn.freebsd.org> <51AC1B49.9090001@mu.org> <20130603075539.GK3047@kib.kiev.ua> <51AC60CA.6050105@mu.org> <20130604052219.GP3047@kib.kiev.ua> <20130604170410.M1018@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Swj79WlilW4BQYVz" Content-Disposition: inline In-Reply-To: <20130604170410.M1018@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 10:43:10 -0000 --Swj79WlilW4BQYVz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 04, 2013 at 06:14:49PM +1000, Bruce Evans wrote: > On Tue, 4 Jun 2013, Konstantin Belousov wrote: >=20 > > On Mon, Jun 03, 2013 at 02:24:26AM -0700, Alfred Perlstein wrote: > >> On 6/3/13 12:55 AM, Konstantin Belousov wrote: > >>> On Sun, Jun 02, 2013 at 09:27:53PM -0700, Alfred Perlstein wrote: > >>>> Hey Konstaintin, shouldn't this be scaled against the actual amount = of > >>>> KVA we have instead of an arbitrary limit? > >>> The commit changes the buffer cache to scale according to the availab= le > >>> KVA, making the scaling less dumb. > >>> > >>> I do not understand what exactly do you want to do, please describe t= he > >>> algorithm you propose to implement instead of my change. > >> > >> Sure, how about deriving the hardcoded "32" from the maxkva a machine > >> can have? > >> > >> Is that possible? > > I do not see why this would be useful. Initially I thought about simply > > capping nbuf at 100000 without referencing any "memory". Then I realized > > that this would somewhat conflict with (unlikely) changes to the value > > of BKVASIZE due to "factor". >=20 > The presence of BKVASIZE in 'factor' is a bug. My version never had this > bug (see below for a patch). The scaling should be to maximize nbuf, > subject to non-arbitrary limits on physical memory and kva, and now an > arbirary limit of about 100000 / (BKVASIZE / 16384) on nbuf. Your new > limit is arbitrary so it shouldn't affect nbuf depending on BKVASIZE. I disagree with the statement that the goal is to maximize nbuf. The buffer cache currently is nothing more then a header and i/o record for the set of the wired pages. For non-metadata on UFS, buffers doenot map the pages into KVA, so it becomes purely an array of pointers to page and some additional bookkeeping. I want to eventually break the coupling between size of the buffer map and the nbuf. Right now, typical population of the buffer map is around 20%, which means that we waste >=3D 100MB of KVA on 32bit machines, where the KVA is precious. I would also consider shrinking the nbufs much lower, but the cost of wiring and unwiring the pages for the buffer creation and reuse is the blocking point. >=20 > Expanding BKVASIZE should expand kva use, but on i386 this will soon > hit a non-arbitary kva limit so nbuf will not be as high as preferred. > nbuf needs to be very large mainly to support file systems with small > buffers. Even 100000 only gives 50MB of buffering if the fs block > size is 512. This would shrink to only 12.5MB if BKVASIZE is expanded > by a factor of 4 and the bug is not fixed. If 25000 buffers after > expanding BKVASIZE is enough, then that should be the arbitary limit > (independent of BKVASIZE) so as to save physical memory. Yes, this is another reason to decouple the nbuf and buffer map. >=20 > On i386 systems with 1GB RAM, nbuf defaults to about 7000. With an > fs block size of 512, that can buffer 3.5MB. Expanding BKVASIZE by a > factor of 4 shrinks this to 0.875MB in -current. That is ridiculously > small. VMIO limits the lossage from this. >=20 > BKVASIZE was originally 8KB. I forget if nbuf was halved by not modifying > the scale factor when it was expanded to 16KB. Probably not. I used to > modify the scale factor to get twice as many as the default nbuf, but > once the default nbuf expanded to a few thousand it became large enough > for most purposes so I no longer do this. Now, with the default UFS block size being 32KB, it is effectively halved once more. --Swj79WlilW4BQYVz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRvEU0AAoJEJDCuSvBvK1BoC0P/itzCFp3T4/ytFNeBhp+OcIS Q1JUd+N9nc+Hni5pIoGwg/XP/BP/EEwABGgCm086uloRzIyeS+4vl1GJfbIvJ3CK 9AfWlEhBFTtlN+7H/WfxrrtAqpsJ8dU9bZG0mdOTYeoDgCE05dJBUCloNug8JPEh vfaXNWhMJRFBCBl1lHTcVnkuVOYLlkMlMbTdbwq4/kAhJt6ym9Pk1Px69hRTGbnQ 4Y76qOK0jYqpaO9Tjjnbk39SfOqqBO7imhXD6conq9E0RfOruXVKuFLAffaz04jX WT+G4kgKPY7rDSNoCy7UgX9myQu6LdpYIj3+dw9RrhoZHN68dk4VbFE0JDMPaVRx c7B5gWNAXOCXngy8vM+2nwD9MlTHd1d0u2OuP9gHPYFvgVEaY//YmiWNMs6yg+j7 pU9WGFgnS+d+dWq2SJo+uSAh4+5UrBK6pTYlCY0BH2u7mF4zcZZGqT1ruUt/XXJ3 ClrZDKwRYPF1f4bmdPSdv92mit92nvSHaXMZhgvUyTod7Og/HQzloz0tjWDE/Aq0 CS1+saGW8Thhplaz7+s94VkZLyuRxfSfcPKq1avxMj2RUT4wPEKRJLh6znWNxVBA XM97xNqrF3LF80Su1kRg1M2s79fxRJtLcj+EfIQFUUYD+wZMtAOR0f9ncDfK45aK a9HTJF1PzYfrxcUxhLW2 =K/Kw -----END PGP SIGNATURE----- --Swj79WlilW4BQYVz--