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:
October 7: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2009 Feb 04 11:58

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



Chanoch (Ken) Bloom wrote:
> 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.

Ah, certainly true.  I just keep users off the nfs server ;-).


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

userspace can use PAE to directly access 64GB, some server applications like
oracle.

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

Applications can ignore PAE, but they can also uses it in user space.
Microsoft provides a AWE (address windowing extensions) to use it... it's very
much like the segment register of old.
_______________________________________________
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.