svn commit: r242029 - head/sys/kern

Alfred Perlstein bright at mu.org
Thu Nov 8 20:17:00 UTC 2012


Peter, can you let me know what you think?

-Alfred

On 11/7/12 11:46 PM, Peter Wemm wrote:
> On Wed, Nov 7, 2012 at 10:24 PM, Alfred Perlstein <bright at 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.

-------------- next part --------------
An embedded message was scrubbed...
From: Alfred Perlstein <alfred at FreeBSD.org>
Subject: svn commit: r242783 - in user/alfred/9-alfred/sys: i386/include kern
Date: Thu, 8 Nov 2012 20:15:13 +0000 (UTC)
Size: 4341
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20121108/2ec758de/attachment.mht>


More information about the svn-src-all mailing list