svn commit: r251282 - head/sys/kern

[Konstantin Belousov]

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.
> 
> 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".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20130604/8c474e6d/attachment.sig>