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 07:21:39PM -0600, Scott Long wrote:
> > 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
>
> The VM_KMEM_SIZE_MAX change came straight from Alan Cox to try to stop
> the bi-daily panics I was getting on a 4GB machine.  Sorry that I'm
> trying to do something about our piss-poor stability.  I bench marched
> this change using 'uptime'.
>
>
> > 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.
>
> Where the 'F' is this comming from??  I don't know why you think I am
> arguing or pushing back on Alfred.  I *WELCOME* people actually thinking
> about our dynamic "auto-tune" limits.  I just wanted to know if he had
> some interested data for what ever values he'd propose.
>

I want to know why the limit that you chose is attributed to me and a
quick suggestion that I made in an email?

> Some of our "auto-tuning" hasn't 't been revisited in a long time -- back
> when 128MB was "large":

It was actually revisited a year ago, around the time of 5.1, but we
quickly outgrew it again due to more use of UMA.

>
>     ----------------------------
>     revision 1.29
>     date: 1998-02-23 07:42:40;  author: dyson;  state: Exp;  lines: +18 -2
>     Try to dynamically size the VM_KMEM_SIZE (but is still able to be
>     ...
>     Two new options "VM_KMEM_SIZE_SCALE" and "VM_KMEM_SIZE_MAX" have been
>     added to support better auto-sizing for systems with greater than
>     128MB.
>     ----------------------------
>
> Everytime I've asked you and phk how we should be deriving some of these
> values all I get is "I don't know, but how we do it today isn't very
> good".
>

I'll say it again.  It's a hard problem.  If I knew the easy answer I
would have committed it long ago.

Scott