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

Re: perspectives on 32 bit vs 64 bit



Faheem Mitha <faheem@email.unc.edu> writes:

> Hi,
>
> Thanks for your comments.
>
> On Fri, 30 Sep 2005, Lennart Sorensen wrote:
>
>> On Fri, Sep 30, 2005 at 03:19:33PM -0400, Faheem Mitha wrote:
>
>>> What is the 4 Gig limit for 32 bit processors that people talk about? Does
>>> this mean that each process/thread can only get a limit of 4 Gig? Is there
>>> any workaround for this?
>>
>> Well given a 32bit program only has 32bit pointers, there isn't any
>> clean simple way to gain more memory.  I believe right now applications
>> can have up to 2GB, although some kernel patches/settings allow up to 3
>> or 3.5GB/application by shrinking the kernel's piece.

Normaly a 32bit i386 kernel supports only 1GB physical memory and has
iirc a 2G:2G split between user and kernel space for virtual memory.

With different options you get 4GB physical ram and a 3G:1G split at
the expense of an extra level for the virtual memory mappings.

The reason for splitting the address space is to have distinct
addresses for user and kernel resources.

> I'm using the stock Debian AMD64 SMP kernel. Do you know what the
> memory value per application is for that?
>
> I don't understand why so much of the memory is taken by the
> kernel. If each application is 4GB, then why is the kernel taking as
> much as 2GB? Does that mean that the application only gets 1/2 the
> memory that the operating system has allocated to it? What is the
> other half being used for?

The amd64 kernel has 64bit addresses and locates itself above the 4GB
limit of 32bit processes. That means that all of the lowest 4GB can be
used by the process without causing overlaps with the kernel. So in
effect all artificial limits are removed and only the limit imposted
by 32bit addresses remains.

MfG
        Goswin



Reply to: