Date: Mon, 15 Dec 2014 15:42:56 -0800 From: Peter Wemm <peter@wemm.org> To: freebsd-stable@freebsd.org Cc: Alfred Perlstein <bright@mu.org>, Ian Lepore <ian@freebsd.org> Subject: Re: i386 PAE kernel works fine on 10-stable Message-ID: <1641407.80FsgLC8bS@overcee.wemm.org> In-Reply-To: <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org> References: <1418579278.2026.9.camel@freebsd.org> <1418580756.2026.12.camel@freebsd.org> <847BD158-0867-4F5F-83A9-1651E77D29EF@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart5987328.3IsdAz3Yqb Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sunday, December 14, 2014 10:53:14 AM Alfred Perlstein wrote: > On Dec 14, 2014, at 10:12 AM, Ian Lepore wrote: > > On Sun, 2014-12-14 at 10:09 -0800, Alfred Perlstein wrote: > >> On Dec 14, 2014, at 9:47 AM, Ian Lepore wrote: > >>> This is an out of the blue FYI post to let people know that despi= te all > >>> the misinformation you'll run across if you search for informatio= n on > >>> FreeBSD PAE support, it (still) works just fine. I've been using= it > >>> (for reasons related to our build system and products at $work) s= ince > >>> 2006, and I can say unequivocally that it works fine on 6.x, 8.x,= and > >>> now 10.x (and presumably on the odd-numbered releases too but I'v= e never > >>> tried those). > >>>=20 > >>> In my most recent testing with 10-stable, I found it was compatib= le with > >>> drm2 and radeonkms drivers and I was able to run Xorg and gnome j= ust > >>> fine. All my devices, and apps, and even the linuxulator worked = just > >>> fine. > >>>=20 > >>> One thing that changed somewhere between 8.4 and 10.1 is that I h= ad to > >>> add a kernel tuning option to my kernel config: > >>>=20 > >>> option KVA_PAGES=3D768=09 # Default is 512 > >>>=20 > >>> I suspect that the most frequent use of PAE is on laptops that ha= ve 4gb > >>> and the default tuning is adequate for that. My desktop machine = has > >>> 12gb and I needed to bump up that value to avoid errors related t= o being > >>> unable to create new kernel stacks. > >>=20 > >> There already is a #define that is bifurcated based on PAE in pmap= .h: > >>=20 > >> #ifndef KVA_PAGES > >> #ifdef PAE > >> #define KVA_PAGES 512 > >> #else > >> #define KVA_PAGES 256 > >> #endif > >> #endif > >>=20 > >> Do you think it will harm things to apply your suggested default t= o this > >> file?>=20 > > I would have to defer to someone who actually understands just what= that > > parm is tuning. It was purely speculation on my part that the curr= ent > > default is adequate for less memory than I have, and I don't know w= hat > > that downside might be for setting it too high. >=20 > KVA pages is the amount of pages reserved for kernel address space: >=20 > * Size of Kernel address space. This is the number of page table pa= ges > * (4MB each) to use for the kernel. 256 pages =3D=3D 1 Gigabyte. > * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). > * For PAE, the page table page unit size is 2MB. This means that 51= 2 pages > * is 1 Gigabyte. Double everything. It must be a multiple of 8 for = PAE. >=20 > It appears that our default for PAE leaves 1GB for kernel address to = play > with? That's an interesting default. Wonder if it really makes sens= e for > PAE since the assumption is that you'll have >4GB ram in the box, wir= ing > down 1.5GB for kernel would seem to make sense=E2=80=A6 Probably mak= e sense to ask > Peter or Alan on this. It's always been a 1GB/3GB split. It was never a problem until certain= =20 scaling defaults were changed to scale solely based on physical ram wit= hout=20 regard for kva limits. With the current settings and layout of the userland address space betw= een the=20 zero-memory hole, the reservation for maxdsiz, followed by the ld-elf.s= o.1=20 space and shared libraries, there's just enough room to mmap a 2GB file= and=20 have a tiny bit of wiggle room left. With changing the kernel/user split to 1.5/2.5 then userland is more=20= restricted and is typically around the 1.8/1.9GB range. You can get a large memory PAE system to boot with default settings by=20= seriously scaling things down like kern.maxusers, mbufs limits, etc. However, we have run ref11-i386 and ref10-i386 in the cluster for 18+ m= onths=20 with a 1.5/2.5 split and even then we've run out of kva and we've hit a= few=20 pmap panics and things that appear to be fallout of bounce buffer probl= ems. While yes, you can make it work, I am personally not convinced that it = is=20 reliable. My last i386 PAE machine died earlier this year with a busted scsi back= plane=20 for the drives. It went to the great server crusher. > Also wondering how bad it would be to make these tunables, I see they= > trickle down quite a bit into the system, hopefully not defining some= > static arrays, but I haven't dived down that far. They cause extensive compile time macro expansion variations that are e= xported=20 to assembler code via genassym. KVA_PAGES is not a good candidate for = a=20 runtime tunable unless you like the pain of i386/locore.s and friends. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart5987328.3IsdAz3Yqb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUj3IEAAoJEDXWlwnsgJ4EkgQIAIj+f+4YMStdhhJB3v3m9EDa 5AELMW3jIZDyiRrC4qdo7EGcc2JjVRPxROup5+8xXpfvSVZgx05nbe0jZ73letoS y0+DS2v5m1YC1f6j0t8aS3ZZmAkMpRX+ibKSiSCXEg9hGZHytBgefzDiXluOwS+3 wzLu0gSIUY10d0NzeyL7J8GjiyRFG2bkfYlkg5hhiTopXW/LKJ8qkUeBNbd8KmIG I4yLhdzGF+zvX8RX9LW44kEUAVRt48xtA9ANA4rklJQt/mU38fNfFCH8DC9obvSj pGEOCn7Y3T/hCFeOz4G40jtU4JNOJC30wV6y6RED3KYXbQvLUMzjlUa5qDVHKcA= =vGGT -----END PGP SIGNATURE----- --nextPart5987328.3IsdAz3Yqb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1641407.80FsgLC8bS>