On 08.11.2012 08:46, Peter Wemm wrote:
On Wed, Nov 7, 2012 at 10:24 PM, Alfred Perlstein <bri...@mu.org> wrote:
[[ + peter ]]
Folks, I spent quite a bit of time trying to figure out how to resolve
maxusers scaling in a happy way for all.
I think I came up with a solution.
This solution should work for i386, and other 32 bit platforms, as well as
scaling well for 64 bit (or higher) platforms that have virtually unlimited
AND 64bit with limited kernel address space.
Here is how it works:
We calculate the maxusers value based on physical memory, and then clamp it
down if physical memory exceeds kernel addressable memory.
The algorithm actually remains the same for all architectures, with the
exception that machines with large kernel address space it is no longer
clamped at 384.
I've attached a test program that lets you play with various values for
VM_MIN_KERNEL_ADDRESS, VM_MAX_KERNEL_ADDRESS and physpages. (argv[1, 2, 3]
respectively.)
Please give me your feedback.
This is still bogus. VM_MIN_KERNEL_ADDRESS and VM_MAX_KERNEL_ADDRESS
have no bearing on how much space should be allocated for mbuf
clusters on amd64. If anything, you want dmapbase / dmapend if you
want a practical cap for amd64. Even then, jumbo clusters are >4K so
they come out of kva rather than direct map.
maxusers is the wrong thing for this. maxusers should, if anything,
be used to set things like kern.maxproc. Preferably it should be
deleted entirely and sysctl.conf should be used to change
kern.maxproc.
Setting limits for the mbuf / cluster pool should be a MD parameter.
Trying to scale maxusers based on physical ram in order to get mbuf
cluster limits set as a side effect is just plain wrong.
It makes no more sense than trying to set nmbclusters based on
PRINTF_BUFR_SIZE, and then trying to scale PRINTF_BUFR_SIZE in order
to get desirable second and third order side effects.
Scale nmbclusters based on physical ram, with a MD method for capping
it for when there are MD limits (eg: disproportionately small kva on
an i386 PAE machine). Don't use maxusers.
ACK
--
Andre
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
