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
(ie Winblows).
Notes:
- 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
in performances.
- 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
board.
Roger
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
