Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Aug 2013 23:32:28 -0700
From:      Alfred Perlstein <alfred@ixsystems.com>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org
Subject:   Re: status of autotuning freebsd for 9.2
Message-ID:  <520DC77C.1070003@ixsystems.com>
In-Reply-To: <51DACE93.9050608@freebsd.org>
References:  <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Andre, I'm kind of bummed out this didn't make it into 9.2, I'm 
wondering can I commit this to 9-stable now?  (or is it already in?)

Would you do the honors?

-Alfred


On 7/8/13 7:37 AM, Andre Oppermann wrote:
> On 07.07.2013 20:24, Alfred Perlstein wrote:
>> On 7/7/13 1:34 AM, Andre Oppermann wrote:
>>> Can you help me with with testing?
>>>
>> Yes.  Please give me your proposed changes and I'll stand up a 
>> machine and give feedback.
>
> http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff
>
> This is functional bundle MFC of these original commits:
>
> MFC r242029 (alfred):
>
>  Allow autotune maxusers > 384 on 64 bit machines.
>
> MFC r242847 (alfred):
>
>  Allow maxusers to scale on machines with large address space.
>
> MFC r243631 (andre):
>
>  Base the mbuf related limits on the available physical memory or
>  kernel memory, whichever is lower.  The overall mbuf related memory
>  limit must be set so that mbufs (and clusters of various sizes)
>  can't exhaust physical RAM or KVM.
>
>  At the same time divorce maxfiles from maxusers and set maxfiles to
>  physpages / 8 with a floor based on maxusers.  This way busy servers
>  can make use of the significantly increased mbuf limits with a much
>  larger number of open sockets.
>
> MFC r243639 (andre):
>
>  Complete r243631 by applying the remainder of kern_mbuf.c that got
>  lost while merging into the commit tree.
>
> MFC r243668 (andre):
>
>  Using a long is the wrong type to represent the realmem and maxmbufmem
>  variable as they may overflow on i386/PAE and i386 with > 2GB RAM.
>
> MFC r243995, r243996, r243997 (pjd):
>
>  Style cleanups, Make use of the fact that uma_zone_set_max(9) already
>  returns actual limit set.
>
> MFC r244080 (andre):
>
>  Prevent long type overflow of realmem calculation on ILP32 by forcing
>  calculation to be in quad_t space.  Fix style issue with second 
> parameter
>  to qmin().
>
> MFC r245469 (alfred):
>
>  Do not autotune ncallout to be greater than 18508.
>
> MFC r245575 (andre):
>
>  Move the mbuf memory limit calculations from init_param2() to
>  tunable_mbinit() where it is next to where it is used later.
>
> MFC r246207 (andre):
>
>  Remove unused VM_MAX_AUTOTUNE_NMBCLUSTERS define.
>
> MFC r249843 (andre):
>
>  Base the calculation of maxmbufmem in part on kmem_map size
>  instead of kernel_map size to prevent kernel memory exhaustion
>  by mbufs and a subsequent panic on physical page allocation
>  failure.
>
>


-- 
Alfred Perlstein




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?520DC77C.1070003>