Re: strange stack limit behavior when allocating more than 2GB mem on 32bit machine

Michał Nazarewicz <[email protected]>
Newsgroups org.kernel.vger.linux-c-programming
Message-ID <[email protected]>
> On Fri, 21 Aug 2009, Joe wrote:
>> Thanks for your explanation. However as you can see, I got 2GB mem and
>> ~10GB swap, totally 12GB.
>>
>> With ulimit -s 10240(KB), I can allocate 2.5GB, I guess these are in
>> swap, right?
>> With ulimit -s unlimited, as you said, kernel reserved 1GB, stack
>> reserved 2GB, there are still 12-3=9GB left??
>>
>> Why did malloc failed, instead of allocating this abundant swap space?

On Fri, 21 Aug 2009 11:37:50 +0200, Nicholas Mc Guire <[email protected]> wrote:
> Initializing 12GB swap will not change the address space limit unless you
> enabled high-memory support in the kernel (CONFIG_HIGHMEM64G=y in your .config)
> the limit is not the physical memory (RAM+swap) but the 32bit address space.

This won't help either since CONFIG_HIGHMEM64G (ie. Physical Address Extension)
affects only physical (not virtual) address space.  Because Joe has 1 GiB
HIGHMEM64G it will only slow his computer down (virtual->physical address
translation requires one more read when HIGHMEM64G is enabled).  Even with
gazillion GiBs of RAM CONFIG_HIGHMEM64G won't help here because the problem
is *virtual* address space limits which is 32-bit on 32-bit x86 systems
(regardless high memory (be it 4G or 64G) being enabled).

-- 
Best regards,                                            _     _
  .o. | Liege of Serenly Enlightened Majesty of         o' \,=./ `o
  ..o | Computer Science,  Micha³ "mina86" Nazarewicz      (o o)
  ooo +----<[email protected]>---<[email protected]>-ooO----(_)--Ooo--

--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.