Bug in VirtualAlloc

[Robert Lunnon]

On Mon, 19 Aug 2002 22:07, David Laight wrote:
> > #define ADDRESS_SPACE_LIMIT  ((void *)0xc0000000)  /* top of the user
> > address space */
> >
> > when making an anonymous mmap Solaris returns
> > 11: ptr = (void *) 0xdf620000
> >
> > Q. Why is there a hard limit on this ? Is this a Windows thing or a Linux
> > thing.
>
> It is actually a hardware feature, IIRC it is the address above which the
> cache ignores process contexts (cache colours).  This means that kernel
> code/data is shared (in the cache) by all processes.
>
> For the sparc reference mmu (used by all sun sparc systems for many
> many years) the address is 0xe0000000.  As someone put it 'the kernel
> has to shoehorn itself into only 512Mb' [1].
>
> I suspect you want to make ADDRESS_SPACE_LIMIT architecture dependant.
> For non-x86 you can (presumably) use OS assigned mmap addresses
> throughout - or is the used of known mmap addresses pervasive?
>
> 	David
>
> (This first became a problem as memory sizes approached 512Mb and it
> no longer became possible to have all of physically memory mapped
> into kernel address space).

OK well judging by Solaris x86 behaviour E0000000 is used there also, and is 
allocated in reverse . I suggest then that I should set ADDRESS_SPACE_LIMIT 
to E0000000 for all Solaris targets.