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:
2009 Feb 04 11:47

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] Kernel not seeing all my RAM
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Kernel not seeing all my RAM

On Tue, 2009-02-03 at 23:49 -0800, Bill Broadley wrote:
> Chanoch (Ken) Bloom wrote:
> > On Tue, 2009-02-03 at 10:28 -0800, Bill Broadley wrote:
> >> Chanoch (Ken) Bloom wrote:
> >>> I'm upgrading an x86
> >> Not x86-64?
> > 
> > There's two machines with this problem. One is really an x86. The other
> > is an amd64, but it's running a totally 32-bit system since it shares
> > home directories by NFS with the first machine (and a couple other
> > 32-bit only machines).
> There is no problem use a 64 bit NFS server and a 32 bit NFS client.

No there isn't, but when people are compiling binaries for one it can
can become confusing if they log in on the other and things don't work.

> > With regard to the amd64, I'd like to have it run a 64-bit kernel with a
> > 32-bit userspace
> Why?  Things like mplayer (with a bunch of codecs), flash, java plugin, dvd
> playback, video encoding, etc "just work".  I've not seen any problems with
> google earth 5.0, picasa, firefox (with plugins), etc.
> >, but the machines are running Gentoo, and I don't know
> > how to do that in Gentoo.
> Unless recently I always installed 32 bit machines for anything with any sort
> of desktop duty.  I didn't want a chroot, didn't want to main two
> environments, didn't want alot of extra hassle... not to mention 4 or more GB
> of ram is pretty pricey.  These days 4GB ram cost $50 or so, things are much
> more mature.
> > (I'm looking at switching these machines to Debian in the long run, and
> > I'll probably start testing that on one machine after lenny is released
> > in a couple weeks, so in the long run I may not need to solve the
> > kernel/userspace thing in Gentoo.)
> I've heard of folks running hybrid with debian, personally I'm running ubuntu
> and it keeps me happy.... I was 100% redhat er, umm, for almost a decade.
> > So you're saying that a 32-bit kernel will map devices in into the 4GB
> > address space in such a way that they hide physical RAM, regardless of
> > whether you're using CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G, and that a
> > 64-bit kernel will map devices differently. Is this right?
> Er.  You are seeing 3GB or so of ram because some devices like video cards
> take memory in the bottom 4GB by default, some PCI devices can only address
> memory in the bottom 4GB.  There are various approaches to handling this,
> linux supports bounce buffers so an I/O device can write to the lower 4GB,
> then the kernel copies it to wherever user space expects it (which can be
> above or below 4GB).  PAE is definitely required, as Cam mentioned I'd try the
> HIGHMEM4G first.  If that doesn't work see if the BIOS mentions anything, then
> if that doesn't work try the 64G setting.
> Unless of course you just want to upgrade to a 64 bit kernel.
> > The definition is probably "Machine Register Size". Pointers, ints, and
> Which registers?  Int?  Floating point?  SSE?

General registers, which are typically used for addresses and ints.

> > addressable memory should go along for the ride because it's convenient
> Addressable memory isn't a particularly good one, after all the last 5
> generations or so of intel chips could address 64GB, but only had 32 bit
> pointers (4GB worth).

Sorry. I meant the memory addressable by a userspace process.

> > to do it that way, but note:
> >       * an int on amd64 gcc is 32 bits. It's a long that's 64 bits.
> Indeed... although that's a language thing more than anything else.  GCC also
> supports 128 bit floats (long double), but that doesn't really say anything
> about the hardware.
> >       * The DOS memory model (*sticks out tongue*) used 16-bit pointers
> >         on 16-bit processors, but addressed 1MB of RAM by the use of a
> >         segment register to choose which "paragraph" of memory pointers
> >         would refer to.
> Right, much like PAE.  Instead of a segment register they play tricks with the
> page tables.  Hopefully 64 bit pointers will prevent any new hacks in there
> area.  Lets so most system max out at around 8 Dimms.  2^64 bytes/8 = 2^61
> bytes.  So until something bigger than 2048 Petabyte dimms become common we
> should be safe.  Maybe then ZFS will makes sense ;-)

As I said above, I was referring to process-addressible memory. PAE is
an issue clearly confined to kernel space. The DOS memory model was in
what passed for userspace.


Ken (Chanoch) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.

Attachment: signature.asc
Description: This is a digitally signed message part

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.