rogerheflin at gmail.com
Wed Oct 15 22:22:33 UTC 2008
Bill Davidsen wrote:
> Roger Heflin wrote:
>> I know a bios engineer once told me that some chipsets/bios can only
>> remap entire dimms (not parts of a dimm) and doing an entire dimm
>> would result in only 2GB below 4GB and that bothers some vendors since
>> it would cause issues with memory availability with 32bit only OSes.
> That's clearly not the case in general, and I've never seen it. Only old
> CPUs would have a problem with it (as a hardware issue), since all x86
> CPUs recently support PAE for 64GB physical memory. I have never seen
> any 32 bit MSFT product use PAE, but the PAE Linux kernels will use more
> than 4GB, which is fine as long as no user program tries to use more
> than 4GB.
The reason was that no 32-bit MSFT product used PAE and they did not want to
cause less memory for the only important (from their point of view) 32-bit OS
> - using PAE results in a performance reduction. I have never found it to
> be a net loss, more memory makes the system faster to a greater extent
> than PAE makes it slower (my experience).
I have also tested PAE/non-PAE and not been able to find a noticeable difference
> - 32 bit versions of many programs run faster than the 64 bit version,
> because they are smaller and nicer to cache. This is another small
> effect, not a big deal.
You can never generalize about 64bit is always faster, some are going to be
faster on 32-bit (as you found) some are going to be faster on 64-bit, too many
people assume that since 64-bit has more registers, and a few extra instructions
that it is always faster than 32-bit.
> - 2.6.27 offers both MTRR "cleaning" and use of PATs. Read the linux
> kernel mailing list and Intel docs for PATs, LKML for MTRR cleaning.
> Short answer is that you are likely to use memory better with 2.6.27 and
> later, that's certainly the case in my experience.
Previous to 2.6.27 linux took the mtrr's that the bios offered and did not mess
with them (except for X adding one for certain drivers). It appears that much
work has gone into linux doing extensive adjustments with the mtrr stuff to make
things more optimal. It likely helps that there are a couple of expert AMD and
Intel guys working on correcting the various bios writes mtrr mess ups.
>> Check to see if any bios settings change things, on the higher end
>> boards there use to be a memory hole setting that could be set to
>> hardware or software, though if I remember correctly setting it such
>> that you found all of the memory also resulting in the machine being a
>> couple of percent slower.
> You show your age by remembering that, and I show mine for remembering
> the details. It seems that some hole settings resulted in using memory
> which couldn't be cached (not enough address bits in cache memory). That
> made the memory so slow that programs were written to use it for swap or
> ramdisk. I had such programs for both MS-DOS and Xenix.
I remember those machines, this was more recent.
The machines that I saw this one were only about 2 years ago and using software
vs hardware memory hole made a 3-5% difference in spec numbers. With one I got
all of the memory but it was 3-5% slower, and in this case the spec number was
more important than having all of the memory. I believe it was a dual socket
More information about the users