Date: Mon, 16 Aug 2004 18:37:00 -0700 From: "David O'Brien" <obrien@freebsd.org> To: Scott Long <scottl@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/include vmparam.h Message-ID: <20040817013700.GB88749@dragon.nuxi.com> In-Reply-To: <20040816191337.B32601@pooker.samsco.org> References: <200408160835.i7G8ZM6d068546@repoman.freebsd.org> <20040816232834.GF57908@elvis.mu.org> <20040817011018.GA67171@dragon.nuxi.com> <20040816191337.B32601@pooker.samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Some of our "auto-tuning" hasn't 't been revisited in a long time -- back
when 128MB was "large":
----------------------------
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".
--
-- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040817013700.GB88749>