Date: Thu, 8 Nov 2012 01:22:33 -0800 From: Garrett Cooper <yanegomi@gmail.com> To: Alfred Perlstein <bright@mu.org> 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: <B48D30C1-5575-467D-96FB-0EDEC4664FFD@gmail.com> In-Reply-To: <509B77C0.9060202@mu.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 8, 2012, at 1:13 AM, Alfred Perlstein wrote: > Peter, >=20 > I agree. >=20 > It's certainly not perfect, however it's not nearly as bogus as what = was there previously. >=20 > 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.... >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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? >=20 > I'm thinking this might suffice to make purists a bit more happy: >=20 > #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...? > #endif >=20 > 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. >=20 > 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! -Garrett=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B48D30C1-5575-467D-96FB-0EDEC4664FFD>