Re: mtrr funnies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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). - 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. - 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.

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.

--
Bill Davidsen <davidsen@xxxxxxx>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux