jhwgh1968 , vor 17 Tagen

@karolherbst I'm sleep deprived today, but doesn't FIXED_NOREPLACE cause pinning, i.e. you can't move or swap it?

If I'm misremembering, then that's probably fine. Look at the heap allocation in "top" of old Golang programs 😄

karolherbst OP , vor 17 Tagen

@jhwgh1968 nah, FIXED_NOREPLACE just means the mmap call won't replace existing mappings.

jhwgh1968 , vor 17 Tagen

@karolherbst then I stand corrected. I say, go for it until something else breaks!

karolherbst OP , vor 17 Tagen

@jhwgh1968 mhhh.. I can't really sub-allocate, because after munmap the original mapping is just gone as well...

though maybe I can make it work without reserving such a huge range, but I'm kinda worried about fragmentation, but... maybe that's fine...

jhwgh1968 , vor 17 Tagen

@karolherbst hence my last comment 😄

lina , vor 16 Tagen

@karolherbst @jhwgh1968 I think what you really want is to logically detach the mapping from the backing (and go back to PROT_NONE) without leaving the address space momentarily available, right? So instead of unmapping you just do a mmap(addr, size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); and that should work I think?

karolherbst OP , vor 16 Tagen

@lina @jhwgh1968 yeah, it should.

Which just brings me back to the original question, if reserving that amount of VM space is a good idea and if there are other options.

I also wonder how well that would work with things like libasan, which just allocates 20TB of virtual memory here.

Anyway, it seems like Intel's CL stack just hopes nothing conflicts and maybe I just do the same, because it should be fine (tm).