From owner-svn-src-head@FreeBSD.ORG Tue Jun 4 05:22:23 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76C3D562; Tue, 4 Jun 2013 05:22:23 +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 DFEE31BCA; Tue, 4 Jun 2013 05:22:22 +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 r545MJrN045672; Tue, 4 Jun 2013 08:22:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r545MJrN045672 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r545MJnJ045671; Tue, 4 Jun 2013 08:22:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 Jun 2013 08:22:19 +0300 From: Konstantin Belousov To: Alfred Perlstein Subject: Re: svn commit: r251282 - head/sys/kern Message-ID: <20130604052219.GP3047@kib.kiev.ua> References: <201306030416.r534GmCA001872@svn.freebsd.org> <51AC1B49.9090001@mu.org> <20130603075539.GK3047@kib.kiev.ua> <51AC60CA.6050105@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pcq5s9LhOxPPc4wB" Content-Disposition: inline In-Reply-To: <51AC60CA.6050105@mu.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: Tue, 04 Jun 2013 05:22:23 -0000 --pcq5s9LhOxPPc4wB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 available > > KVA, making the scaling less dumb. > > > > I do not understand what exactly do you want to do, please describe the > > algorithm you propose to implement instead of my change. >=20 > Sure, how about deriving the hardcoded "32" from the maxkva a machine=20 > can have? >=20 > 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". --pcq5s9LhOxPPc4wB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRrXmKAAoJEJDCuSvBvK1Bwt4QAKO045Ea2neD2dW9NYeuEVpA R3VKd8PXfJ8oc+w29mIv035NLQwqJ6Wu+hc9aTcMq/DwyAjaKOSWqId1z6F6uMA5 ufoDkttshd9AAkNL7S7f5YTvap4XL3S/JZNjrWIoJH55nlTOy1QrnHCRJZ9VDvYb bibFNWxTkpjKJD6Zb+Ole7MCEx2Ox+yjVC0d7oDxMUJC4NirxN3JyFPWdzeqllWH zf58PZmN8kMvuBspfyYf2wHbVLyx3lngXa/ZqlqkklHenaPuSP1MvKnhNG/YlXPx CuLL77SPBCpMR9FMnMa6Ro0b54MwQ5+JkD3xokuVVS3mRGSUeRXvyR689FP7/Jdu EX+2GNJnjQAQMle0RcbSVb1EpeHfHC2i/011JyNxCIQv7Hh5XJ5cxNYPW6H/piX2 J4RbEAy1hvsYpbzE8J2tCT5ChiDCMDX8PGIXICEr6bZpLjWNatO9sS8x8PA040+1 jSBo7DO2aslJZkPtqQ9/WnWvtc9bW93jjGgtvWbP7MS41Ub+iW57SKmlol61Yjf+ wzvaHh9po3/pFqIuac1mt+T0OqeuJouviH6qeL4tnXo0PhYrQJxT+l92C/DMu7rr i1Y/fLF6e+ccnA36+PX84TJdIvJUWJ+DPTbBHmNS0N5DS77h6DfrcNaObbO4JZdT cHaM3UBPUIXQb/ZIrKDe =pc8H -----END PGP SIGNATURE----- --pcq5s9LhOxPPc4wB--