On 6/10/19 3:40 PM, Yu-cheng Yu wrote:

Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and
VM_DONTDUMP.  The bitmap will cover only 48-bit address space.

Could you make sure to discuss the downsides of only doing a 48-bit
address space?

What are the reasons behind and implications of VM_DONTDUMP?

We then create PR_MARK_CODE_AS_LEGACY.  The kernel will set the bitmap, but it
is going to be slow.

Slow compared to what?  We're effectively adding one (quick) system call
to a path that, today, has at *least* half a dozen syscalls and probably
a bunch of page faults.  Heck, we can probably avoid the actual page
fault to populate the bitmap if we're careful.  That alone would put a
syscall on equal footing with any other approach.  If the bit setting
crossed a page boundary it would probably win.

Perhaps we still let the app fill the bitmap?

I think I'd want to see some performance data on it first.