Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 08 Nov 2012 04:56:25 -0800
From:      Alfred Perlstein <bright@mu.org>
To:        Garrett Cooper <yanegomi@gmail.com>
Cc:        src-committers@freebsd.org, Peter Wemm <peter@wemm.org>, John Baldwin <jhb@freebsd.org>, svn-src-all@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, svn-src-head@freebsd.org
Subject:   Re: svn commit: r242029 - head/sys/kern
Message-ID:  <509BABF9.9040003@mu.org>
In-Reply-To: <B48D30C1-5575-467D-96FB-0EDEC4664FFD@gmail.com>
References:  <201210250146.q9P1kLi8043704@svn.freebsd.org> <20121025080551.GG35915@deviant.kiev.zoral.com.ua> <201210250950.57161.jhb@freebsd.org> <509B501F.5050109@mu.org> <CAGE5yCobr4ZU0DEWZSez1kp4jo_V4gSby0kGqFF06Dev_Cc_jA@mail.gmail.com> <509B77C0.9060202@mu.org> <B48D30C1-5575-467D-96FB-0EDEC4664FFD@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11/8/12 1:22 AM, Garrett Cooper wrote:
> On Nov 8, 2012, at 1:13 AM, Alfred Perlstein wrote:
>
>> Peter,
>>
>> I agree.
>>
>> It's certainly not perfect, however it's not nearly as bogus as what was there previously.
>>
>> I know "maxusers" is "wrong", however what it really means, if you think about it, is "give me a scaling factor that is relative to physical ram, BUT capped at some value so as to not exhaust KVA." Yes, I grok that on certain architectures that mbufs clusters aren't pulled from KVA, but, that seems much less important than how broken it is currently....
>>
>> This fix is "good enough" for the general case, and a far greater improvement than what was there previously which would make FreeBSD blow chunks on any sort of 10gigE load.
>>
>> I think what needs to happen here, is that the people requiring perfection think about what mess it was prior and if they themselves do not have time to make it 100% perfect, allowing someone to step in and move something
>> a step in the right direction without overly complicating it.
>>
>> What is there is crap, it's old, crufty and broken, it really is. It needs to be fixed, it needs to be given a nice fat band-aid now, and when someone interested in perfection comes along, then they can make it even more awesome.
>>
>> I am not saying that my fix is PERFECT or the be all and end all, however it serves as a good step in the right direction on our tier 1 platforms and is easily modifiable (just replace "VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS" with some form of MD magic sauce.)  Would you like me to do that?  Replace the hardline calculation with some constant that each platform can configure?
>>
>> I'm thinking this might suffice to make purists a bit more happy:
>>
>> #if defined(i386) || defined(amd64)
>> #define MAX_KERNEL_ADDRESS_SPACE (VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS)
>> #else
>> #define MAX_KERNEL_ADDRESS_SPACE  (1024*1024*1024)
> Only 1GB for KVA on 64-bit platforms too...?
Sure, if there's any people paying attention for these platforms they 
can quickly provide the necessary #define for the platform. (To make it 
MD as Peter suggested.)   I guess I could #error until people catch up?  
That seems rude though.

The way this works is that platforms that aren't listed get the old 384 
cap, if they want more, then they can give me the #defines needed for 
better autotuning.

Truth be told this is basically what Peter said to do, however just 
keeping the name maxusers.

Yes maxusers is gross, but a step forward which unfortunately retains it 
needs to happen now.

>> #endif
>>
>> Given my algorithm this should result in pretty much the same for other platforms than amd64 which will then be able to grow maxusers some.
>>
>> I'm basically running out of time on this and I'm worried that I'll have to back it out indefinitely so that FreeBSD can't do 10gigE out of the box.
> I agree with the philosophy being taken. Perfection shouldn't be the enemy of the good as long as it gets close enough that things are more useful than they are today.
>
> Thanks for championing this Alfred. The less voodoo required for FreeBSD to function on commodity hardware, the better!
>
The less voodoo required to commit simple patches that take us forward 
the better as well.

One shouldn't be tasked with redesigning rewiring an entire house just 
because they want to change one outlet.

-Alfred



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?509BABF9.9040003>