Date: Sat, 15 Jun 2013 13:43:01 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r251282 - head/sys/kern Message-ID: <20130615104301.GL91021@kib.kiev.ua> In-Reply-To: <20130604170410.M1018@besplex.bde.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130615104301.GL91021>