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.


--
Andre

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to