Regarding the page / map size: At first I tried this with larger sizes (around 98 kb), but no difference.
Johnny wrote: > What is the pagesize of the machine? pagesize yields 4096 on the system in question, so it shouldn't be of relevance, I guess. Michael wrote: > But the start address in the test program is aligned to something much > larger, so the first test should succeed if that was the problem. I > wouldn't bet on the address range used being available though, but > that's just a hunch. Why shouldn't the range be available, though? /proc/PID/maps does not show any mapping in this range. Is there some kernel related mapping that doesn't show up in /proc/PID/maps? Michael wrote: > Also, why MMAP_FIXED in the first place? Actually I don't know. A lot of CLISP's code is pretty old, so I'd guess it's just a remnant or maybe due to portability to operating systems that cannot search a free address range in virtual memory. Michael wrote: > Finally, mmap()ing 1TB will probably run into all sorts of other > problems before hitting mmap() itself. If the underlying filesystem is > ffsv1 it probably doesn't even support files that big. Hm, the example program is a bit misleading here. I don't intend to map such a big region, the programs purpose was to find a (0x1000, thus a single page) address range where mmap with MAP_FIXED works. Every single call to mmap in that example program fails. Martin wrote: > # define TRY_EMPTY_VM_SPACE 0xb0000000 Using this address actually works :) So I guess for some reason I cannot mmap addresses as high up as 0x4000000000000 ... the questions is: Why, when it seems to be unmapped?
