l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2007 Jan 24 12:46

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] New notebook computer for Linux - AMD or
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] New notebook computer for Linux - AMD or

Jeff Newmiller wrote:
Kevin Hrim wrote:
What we have run into is that the new Laptops may have dual core 64bit
processors, and stated capability of 4Gb installed memory.  But, the
path from processor to memory is only 32 bits wide.
This assertion is vague: there are two paths involved here.  One is
the data path, and the other is addressing.
Actually there is only one, the FSB, that handles both.  Additionally so-dimms
are 64-bit wide.

A 32-bit data path only
means the processor has to fetch twice to fill its internal 64-bit
registers, which can slow certain memory-intensive activities down.
Well registers are generally filled from cache, which is definitely
at least 64 bits wide.   L2 cache is filled from main memory, thats
usually 64-128 bytes 64 or more often 128 bits at a time.

As for addressing, it has been common for motherboard manufacturers
to implement only a subset of the address connections to the memory
since forever.  Early macintosh computers using the 68000 processor
had fewer than 24 bits of address lines... the operating system was
actually written to store extra information in the upper 8 bits of
each address to use available memory efficiently.

Note that the number of implemented address lines is entirely at the
discretion of the mobo manufacturer... and there is nothing that says
it has to be a multiple of 8 address lines (bits).[1]  However,
in these days of very large integration, those decisions tend to
get made inside various support chips and new versions of those can
take time to reach market.  The mobo manufacturer may design their
own ASICs and bypass that... but big companies like Dell prefer
not to have to support such custom chips through a full lifecycle.
Right, even 64 bit CPUs usually have 36-48 address lines, 32 bit
machines usually 32 lines, that has nothing to do with memory
bandwidth though.  Even 32 bit CPUs almost always (in recent history
anyways) transfer from memory 64 bits at a time from main memory and
even more than 64 bits per cycle from cache.  Even the high end
alpha, pa-risc, opteron, and xeons have less than 64 bits
or addressing.

Even the fairly low end intel/amd sockets and cpus transfer
from memory 64 bits wide, and usually at least twice the frequency
of the main memory bus.  I.e. 64 bits @ 800 MHz coupled with
a 128 bit wide 400 MHz memory interface.  It can be
configured with a 64 bit wide memory interface, but I can't
imagine 32.

Ability to use > 2GB ram basically means that at least 32 bits
of address are available.

A good sign of a 128 bit memory bus is having to add dimms in pairs,
pretty common on the current laptops.  The integration you speak
of is the north bridge on intel machines, and there are very few
indeed, I think 2 currently for most markets.  AMD is exactly
1 since it's inside the CPU.  Anything AMD based, even on a laptop
supports a 128 bit wide memory bus, I believe there is 64 bit
compatibility if you wanted to use less dimms and save some
traces on the motherboard.  Hard to imagine a platform
supporting only 32 since you couldn't even use standard dimms.

I am not too surprised, really... the time-to-market pressures cause
them to adapt existing designs with a minimum of modification so
people can gain the benefits of the internal processor functionality.
Er, this is an OS issue, not hardware, if he's addressing > 2GB he's
got a full 32 bit of addressing.

Reserving the upper 640MB implies that they use the top five bits out
of 32 supported by their existing mobo interface circuitry to
determine whether to access the RAM or BIOS (flash, probably).
Er, that's not how it's done, it's just an address range.

Thus, I doubt that any BIOS upgrade [2] is going to fix this.
Agreed, it's related to the kernel.  I've seen upgrades to the
kernel greatly increase the available ram on 4GB ram machines,
especially on 64 bit machines.

However, it is a useful warning for others to pay attention to
the motherboard specifications for maximum amount of supported RAM
when looking to purchase if the reason for purchasing is to get
access to more memory.  Unfortunately, I don't know of a good way
to find out the data bus width... it is often multiplexed for access
to busses such as PCI anyway, so specifying which peripherals are
This is a very strange idea, multiplexed is the wrong word, the
FSB handles both, but it's as needed, and I/O is almost always a small
fraction of memory bandwidth except when really pushing things
with graphics and in that case only on the intel.

The reason for seeing 3.0-3.5 GB available has to do with various
memory ranges that have different purposes. A copy of BIOS, video
memory, memory mapped interfaces to video cards, etc. It's common
for even a 64MB video card to require 256MB of address space. A
smarter 64 bit OS + 64 bit kernel can just map all the real ram
else where and still map all the legacy/IO/video stuff under
4GB. For instance:
root@lanczos:~# free
total used free shared buffers cached
Mem: 4044804 3538316 506488

cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1

So note that there's 4GB at 0 of ram, then an entire a 1GB area marked
uncachable, that's where the I/O devices and video card maps are. This
allows even stupid 32 bit hardware and/or drivers to still work in the
64-bit hardawre/OS since by definition all the addresses will be below
4GB (the max addressable by 32 bits).

Any recent CPU in the p4, athlon, xp, turion, and celeron families, can address > 4GB ram, PAE is common, and broken I/O systems that require under 32 bits can be worked around in various ways, bounce buffers below 4GB is a common method to allow older "32 bit" machines to access > 4GB ram.

With all that said, I'm not surprised that microsoft 32 bit or
64 bit OSs don't take advantage of it.

So for linux check out the PAE options if using 32 bit hardware or
kernel, and the later kernels if on 64 bit to make the most of those
4 1GB dimms. The "missing" 640MB should be able to be mapped elsewhere
and give you most of the 4GB available.

BTW the dell URL confirms that the mentioned hardware has a 128 bit
wide memory interface, and that it can directly address at least
32 bits worth.
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.