Date: Fri, 16 Aug 2013 10:29:58 +0200 From: Andre Oppermann <andre@freebsd.org> To: Alfred Perlstein <alfred@ixsystems.com> Cc: stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org Subject: Re: status of autotuning freebsd for 9.2 Message-ID: <520DE306.4080004@freebsd.org> In-Reply-To: <520DC77C.1070003@ixsystems.com> References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> <520DC77C.1070003@ixsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16.08.2013 08:32, Alfred Perlstein wrote: > 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?) It didn't make it because there was only sparse feedback after the call for testers. There were a couple of replies that it is being tested but no statements either way if it was good or not. Hence I erred on the side of caution and refrained from committing it. > Would you do the honors? Yes, will do later today. -- Andre > -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. >> >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?520DE306.4080004>