l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
August 5: Social gathering
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2007 Jan 23 22:02

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



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

So, our Dell D820's have two 2Gb sticks of memory, but only report 3.3
Gb useable.  The remainder (640mb) is reserved for system use (yea,
right)
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.

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).
Thus, I doubt that any BIOS upgrade [2] is going to fix this.
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
accessed with 64-bit-wide data and which use successive narrower
accesses is a losing battle for the manufacturers and unlikely to
make a difference in your purchase decision.

[1] The cpu still may internally specify 32 or 64 bits, but the
upper bits may never make it outside the cpu (depends on the particular
variant of the cpu)... and if they do, they may be ignored.
This creates a kind of "hall of mirrors"
in the physical memory space... ignoring the top bit divides
physical memory into two halves, and changing a data bit in one
half causes that bit in both halves to change. Ignoring two
bits makes four "copies"... three makes eight "copies"...
and so on. Fortunately, our operating systems use virtual
memory to hide all this these days... you may find
functional RAM accessible anywhere in your virtual address
space, but accessing a virtual address that the OS hasn't
set up will stop the software if that software starts
sniffing around too much. In this case, it sounds like there
are 4 billion copies of physical memory, and 64MB of each
4GB "copy" is being directed at memory other than the RAM.

[2] http://blogs.conchango.com/jameshayes/archive/2006/10/26/Dell-D820-4GB-memory-problem-_2800_Part-3_2900_.aspx

--
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<jdnewmil@dcn.davis.ca.us> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...1k
---------------------------------------------------------------------------
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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:
O'Reilly and Associates
For numerous book donations.