Newbie on linuxquestions, so flame away if I've posted to the wrong forum or what have you.

Anyway, according to the release notes, RHEL 6 has a PAE enabled kernel by default. Great... But that leaves me wondering why uname report SMP. Further, I'm provisioning some systems for QA use, and they're asking that PAE is disabled. My thinking is that since RHEL 6 requires PAE capability to install, there may be no way to disable it and the googling I've done seems to support this. Am I wrong?

tl;dr

Why does a default kernel with PAE enabled report SMP on RHEL 6?
Can PAE disabled on RHEL 6?

a) PAE and SMP are not mutually exclusive.
b) Likely not.

Interesting - I hadn't noticed that requirement. Not to mentionThat is a hardware requirement. I'd be willing to bet Anaconda might actually test for this, but once the install is finished you may (note may) be able to turn it off in the BIOS. If so, do it - the kernel supports PAE, but doesn't require its presence even if the option is selected in the (kernel) build.

1 members found this post helpful.

I found my answer elsewhere thanks. AlucardZero, you might try throwing a helpful comment out rather than snark. Syg00, thanks.

I don't understand; I was not snarky. I answered your questions. Brief, sure (we prefer to call it efficient), but not impolite.

Also, can you post the answer you found here so that other people can find it?

1 members found this post helpful.

I've never seen that in any BIOS, and I think I know enough about PAE to know that doesn't make sense. It isn't a feature the BIOS would be able to turn off even if it wanted to.

What is your basis for that claim?

I know Windows 32-bit kernels are compiled to be able to decide at kernel load time between PAE and non PAE. So obviously it is possible to build a kernel that way. But I didn't think Linux did so.

I thought a PAE Linux kernel can only work with PAE enabled. But I never tested it (ran a PAE kernel on a CPU without PAE or somehow disabled PAE on a CPU that supports it). Have you?

Hmmm - good question. I've certainly run 32-bit kernel with less than 4 Gig on PAE enabled machines that contained 8 Gig RAM. Not the same thing, but close as the code for > 4Gig wouldn't be exercised. Wouldn't guarantee it was all real below 4 Gig (real) though of course.
We just tossed the last of those (original) Xeon servers - would have been interesting (now ) to look at the BIOS. Turning off access to the extra addressing line(s) would certainly be possible as an option.

Simple solution would be to ensure the machine for the QA folks only had 4 Gig (max) memory it.

Censure accepted.

I'm still in disagreement with you, but

No censure was in any way intended.

I don't think it is "close", because even though the purpose of PAE is supporting over 4G, there isn't any significant code in PAE support specific to use or support of ram over 4GB.

In 32-bit non PAE, each page table has 1024 entries of 4 bytes each. In both PAE and 64-bit mode, each page table has 512 entries of 8 bytes each. That is the biggest difference between PAE and non PAE.

When PAE is enabled, all page table entries are 8 bytes each. There is not a kludge of 4 byte page table entries for the first 4GB of physical ram and 8 byte entries for the rest. If PAE (or 64 bit mode) is on, all page table entries are 8-bytes.

Also in 32-bit non PAE 1024 page tables is the max that could be needed to define one process's full (user plus kernel) address space and 1024 page tables can be pointed to by one page directory. So each process has only one page directory.

In PAE mode, 2048 page tables would be needed for the whole address space and a page directory can only point to 512, so four page directories may be needed per process. None of that is affected by having less than 4GB physical ram. If PAE is enabled, you need the extra structure to point to the four possible page directories (if 64-bit mode is enabled, you need a much larger extra structure to point to potentially very many page directories and you need that even for 32 bit processes that can't use very many).

Having less than 4GB doesn't automatically turn off PAE (my best guess is nothing short of recompiling the kernel turns off Linux PAE), nor is it in any way "close". So depending on why QA wants what they requested, that "solution" is somewhere in the range from mostly wrong to absolutely wrong.

I'm not that clear on what the QA folks hope to achieve by testing (an application?) on a non PAE 32-bit system. Probably they just want some kind of completeness to the testing, without have any specific possible issues in mind.

If they are testing application (as opposed to device drivers), I think they are being stupid. PAE has incredibly little effect on applications.

Even in a driver, a bug that makes it work for PAE and fail for non PAE is very unlikely. Before PAE was common, lots of programmers were sloppy and coded drivers that would not be portable outside of 32-bit non PAE x86. Most such drivers that wouldn't work for PAE also would work when simply recompiled for 64-bit. But there were also a few possible bugs that broke a driver for PAE but wouldn't break recompiled for 64-bit.

But if you correct a driver for PAE, that is not at all likely to break it for non PAE.

Back on the QA question, I understand the organizational pressures behind testing across every difference that has been identified as a possible issue. But that policy is still wrong. (Assuming you have customers) there are important differences between the QA machines and the customer machines that you haven't identified as testing categories. Any identified categories (such as non PAE) that are nearly meaningless serve as distractions that delay discovery of more important differences QA ought to be worrying about.