Date: Wed, 15 Oct 2014 08:15:13 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Terry Kennedy <TERRY@tmk.com> Cc: freebsd-arch@freebsd.org Subject: Re: [rfc] Add boot-time warning messages to PAE kernels Message-ID: <1413382513.12052.444.camel@revolution.hippie.lan> In-Reply-To: <01PDRGFBJ8CO000821@tmk.com> References: <01PDRGFBJ8CO000821@tmk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2014-10-15 at 03:35 -0400, Terry Kennedy wrote: > Well, that didn't go over well at all. Makes me wonder if I was being > set up by somebody... > > Personally, I have nothing in this either way. My only experience with > the subject area is seeing repeated questions about this on the forums > and mailing lists. To address a number of the points raised: > > > No no no no no. People who are smart enough to build themselves a > > different kernel should not get their noses rubbed in your idea of > > what's right every time they boot. I run a PAE kernel for my own > > reasons, and they are good reasons for me regardless of what you think > > about it. > > They generally show up asking how to build a PAE kernel, because they > were led somehow into thinking that PAE was the answer to their problem. > Or they managed to build a PAE kernel, but it didn't fix whatever the > meta-issue was that led them to PAE in the first place. > > This wasn't helped by the fact that various documents described the > FreeBSD amd64 support as "experimental" until quite recently. For example > r248857 finally took it out of the hardware notes. > > Perhaps if we can find out where users are obtaining incorrect advice > to use a PAE kernel instead of amd64, those sources can be corrected as > well? > Perhaps it's the 'amd' in the name? That always struck me as insane, but it's too late to change now. > > And can we finally lose the mythology that PAE is somehow experimental > > or inadequate? I've never encountered a driver that doesn't work with > > PAE (I'm sure they exist, but again, people smart enough to build a > > custom kernel should be smart enough to deal with testing it with the > > devices they use). > > Well, a "grep nodevice /sys/i386/conf/PAE | wc -l" reports 46 "nodevice" > statements disabling hardware which is not supported by the PAE kernel, as > well as a complete disabling of module building. > The fact that we actively propagate the myth doesn't make it right. The comment even notes that the drivers are "either don't work or untested" I suspect most fall into the latter category. I use a couple devices on the list. I use modules as well, despite the comment that that doesn't work. > > PAE is the way to get NX bit on 32bit kernels. > > Educate me here - is this non-amd64-capable hardware being used in a > production environment, or amd64-capable hardware being run in i386 mode > for some reason? I haven't run into any i386 user code that wouldn't run > on a FreeBSD amd64 kernel, so I'm trying to see why PAE is the desired > solution here. > I didn't say that, and I have no idea what it means. > Feel free to go "Because I do, the reasons are none of your business", > but I'm genuinely interested. > > In particular, the several replies saying that for business reasons there > can be no warnings would seem to be incompatible with running long out-of- > production / out-of-warranty hardware (for the non-amd64-capable case). > I'm not sure where you got the idea that i386 hardware is long out of production. google "industrial single-board computer" some time for an alternate take on what's producing and shipping and still in control of a non-trivial slice of our daily lives. When we ship i386-based products at $work it's using brand new hardware. Sure, some of the hardware we ship with i386 kernels could actually run with amd64 kernels, if we wanted memory usage to go up without any noticible improvement (and perhaps a noticible degradation) in the product's overall performance. There is still important work being done in systems with 256MB or even 64MB of ram. The whole world is not solving the same problems Netflix and Isilon run into every day. > > The real issue with PAE is that auto-tuning easily makes non-working > > configuration due to small KVA (1 or 2 GB) comparing with the available > > physical RAM installed on the machine. It is more or less fine for 4GB > > machine, but AFAIR, is on the edge for 8GB, and breaks afterward. > > Lowering the user/kernel VA split helps somewhat. > > > > The solution for PAE issues is to implement separate address space for > > kernel. It would add some overhead on each mode switch, but this is the > > cost of being able to run what you need. > > This would seem to be an area in need of improvement. But if it doesn't > affect the experienced people who are running PAE kernels for good reason, > it just becomes another pitfall new users will have to learn about the hard > way. > I'm running PAE on this desktop machine so that when I do builds for our i386-based products for work, they're not cross-builds. This machine has 12GB of ram and I've never had a problem with running out of kva. I can imagine there would be configs and workloads where that would be a problem. -- Ian > > I'd add a && !stfu_warn64 in there somewhere that's set as a tunable. It > > is a good seat belt for the newbie running the wrong thing (though maybe > > 7 years too late), but experienced users may wish to stifle it for > > organizational reasons. > > Well, it's only 18 months too late if we start when the errant "amd64 is > experimental" was excised from the hardware notes. > > I agree that a tunable in loader.conf makes perfect sense. That's why I > prefaced this part of my original post with "[Possibly]". > > Terry Kennedy http://www.tmk.com > terry@tmk.com New York, NY USA > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1413382513.12052.444.camel>