Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Nov 2012 15:21:14 -0800
From:      Alfred Perlstein <bright@mu.org>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        "src-committers@freebsd.org" <src-committers@freebsd.org>, Eitan Adler <eadler@freebsd.org>, Peter Wemm <peter@wemm.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Alfred Perlstein <alfred@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r242847 - in head/sys: i386/include kern
Message-ID:  <17959D7E-4F3C-4513-91F2-3CDDE3A0D41A@mu.org>
In-Reply-To: <509EDD93.3020001@freebsd.org>
References:  <201211100208.qAA28e0v004842@svn.freebsd.org> <CAF6rxg=HPmQS1T-LFsZ=DuKEqH30iJFpkz%2BJGhLr4OBL8nohjg@mail.gmail.com> <509DC25E.5030306@mu.org> <509E3162.5020702@FreeBSD.org> <509E7E7C.9000104@mu.org> <CAF6rxgmV8dx-gsQceQKuMQEsJ%2BGkExcKYxEvQ3kY%2B5_nSjvA3w@mail.gmail.com> <509E830D.5080006@mu.org> <509E847E.30509@mu.org> <CAF6rxgnfm4HURYp=O4MY8rB6H1tGiqJ3rdPx0rZ8Swko5mAOZg@mail.gmail.com> <509E8930.50800@mu.org> <CAF6rxgmabVuR0JoFURRUF%2Bed0hmT=LF_n5LXSip0ibU0hk6qWw@mail.gmail.com> <CAGE5yCouCWr4NKbgnjKfLcjc8EWqG0wRiSmXDDnrnM3%2BUc8KVQ@mail.gmail.com> <CAF6rxg=ryNEMEidJdgf8-Ab=bD15R1ypcz-bS8183U4JK_Q17g@mail.gmail.com> <CAGE5yCoeTXf7x4ZBDXnHJ4dnFi-_2R28kB8HxOB%2B=Je4aJGYQQ@mail.gmail.com> <509EA869.6030407@freebsd.org> <509ED439.8090607@mu.org> <509EDD93.3020001@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 10, 2012, at 3:04 PM, Andre Oppermann <andre@freebsd.org> wrote:

> On 10.11.2012 23:24, Alfred Perlstein wrote:
>> On 11/10/12 11:18 AM, Andre Oppermann wrote:
>>> On 10.11.2012 19:04, Peter Wemm wrote:
>>>> This is complicated but we need a simple user visible view of it.  It
>>>> really needs to be something like "nmbclusters defaults to 6% of
>>>> physical ram, with machine dependent limits".  The MD limits are bad
>>>> enough, and using bogo-units like "maxusers" just makes it worse.
>>>=20
>>> Yes, that would be optimal.
>>>=20
>> No it would not.
>>=20
>> I used to be able to tell people "hey just try increasing maxusers" and t=
hey would and suddenly the
>> box would be OK.
>>=20
>> Now I'll have to remember 3,4,5,10,20x tunable to increase?
>=20
> No.  The whole mbuf and cluster stuff isn't allocated or reserved
> at boot time.  We simply need a limit to prevent it from exhausting
> all available kvm / physical memory whichever is less.
>=20
> Other than that there is no relation to maxusers except historic
> behavior.
>=20
> So the ideal mbuf limit is just short of keeling the kernel over
> no matter what maxusers says.  There also isn't much to tune then
> as the only fix would be to add more physical ram.

I think that makes sense.  If you have ideas please look into it.=20


-Alfred



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17959D7E-4F3C-4513-91F2-3CDDE3A0D41A>