powerpc64 malloc limit?

Kostik Belousov kostikbel at gmail.com
Wed Nov 30 16:24:28 UTC 2011


On Wed, Nov 30, 2011 at 06:24:41AM +0100, Andreas Tobler wrote:
> All,
> 
> while working on gcc I found a very strange situation which renders my 
> powerpc64 machine unusable.
> The test case below tries to allocate that much memory as 'wanted'. The 
> same test case on amd64 returns w/o trying to allocate mem because the 
> size is far to big.
> 
> I couldn't find the reason so far, that's why I'm here.
> 
> As Nathan pointed out the VM_MAXUSER_SIZE is the biggest on powerpc64:
> #define VM_MAXUSER_ADDRESS      (0x7ffffffffffff000UL)
> 
> So, I'd expect a system to return an allocation error when a user tries 
> to allocate too much memory and not really trying it and going to be 
> unusable. Iow, I'd exepect the situation on powerpc64 as I see on amd64.
> 
> Can anybody explain me the situation, why do I not have a working limit 
> on powerpc64?
> 
> The machine itself has 7GB RAM and 12GB swap. The amd64 where I compared 
> has around 4GB/4GB RAM/swap.
> 
> TIA,
> Andreas
> 
> include <stdlib.h>
> #include <stdio.h>
> 
> int main()
> {
>          void *p;
> 
>          p = (void*) malloc (1152921504606846968ULL);
>          if (p != NULL)
>                  printf("p = %p\n", p);
> 
>          printf("p = %p\n", p);
>          return (0);
> }

First, you should provide details of what consistutes 'the unusable
machine situation' on powerpc.

That said, on amd64 the user map is between 0 and 0x7fffffffffff, which
obviously less then the requested allocation size 0x100000000000000.
If you look at the kdump output on amd64, you will see that malloc()
tries to mmap() the area, fails and retries with obreak(). Default
virtual memory limit is unlimited, so my best quess is that on amd64
vm_map_findspace() returns immediately.

On powerpc64, I see no reason why vm_map_entry cannot be allocated, but
please note that vm object and pages shall be only allocated on demand.
So I am curious how does your machine breaks and where.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20111130/4f21160e/attachment.pgp


More information about the freebsd-arch mailing list