cvs commit: src/sys/i386/include vmparam.h

[Scott Long]

On Mon, 16 Aug 2004, David O'Brien wrote:
> On Mon, Aug 16, 2004 at 04:28:34PM -0700, Alfred Perlstein wrote:
> > * David E. O'Brien <obrien at FreeBSD.org> [040816 01:35] wrote:
> > > obrien      2004-08-16 08:35:22 UTC
> > >
> > >   FreeBSD src repository
> > >
> > >   Modified files:
> > >     sys/i386/include     vmparam.h
> > >   Log:
> > >   Increase the scaling of VM_KMEM_SIZE_MAX.
> >
> > Is there any chance we can scale up the max sockets/maxfiles a bit?
> >
> > I've found that for simple benchmarks, doubling or quadrupling
> > didn't see to cause any instability would make us look better out
> > of the box.
>
> The increase of VM_KMEM_SIZE_MAX is prevent (help delay?) panics on 4GB
> i386 systems.  Do you have benchmark data suggesting what would be better
> values for max sockets/maxfiles?
>

The whole point of dynamic limits was to help auto-tune the system using
the assumption that someone who spends money on more RAM is likely to have
a workload that is more server-oriented (and thus needs more sockets
and/or vnodes).  The limit that you committed was based on an off-handed
comment that I made with the intention of getting the number to a value
so low that it would be very safe.  Why you are committing numbers without
doing your own extensive benchmarking and testing is quite beyond me.  The
reason that this wasn't done yet by someone else is not because everyone
is lazy, it's because it's a very hard and time-consuming problem to solve.
Stealing numbers out of thin air is easy but not really conducive to having
a well-performing system.  I thought that you would understand and
appreciate this already.

I'm also unclear on why you are raising VM_KMEM_SIZE_MAX but arguing with
Alfred over raising kern.maxvnodes.  They have a close relationship to
each other, and I don't see why you are resistant to recognise that.

Scott