> On Jun 10, 2019, at 3:59 PM, Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > >> 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. Trying to summarize: If we manage the whole thing in user space, we are basically committing to only covering 48 bits — otherwise the whole model falls apart in quite a few ways. We gain some simplicity in the kernel. If we do it in the kernel, we still have to decide how much address space to cover. We get to play games like allocating the bitmap above 2^48, but then we might have CRIU issues if we migrate to a system with fewer BA bits. I doubt that the performance matters much one way or another. I just don’t expect any of this to be a bottleneck. Another benefit of kernel management: we could plausibly auto-clear the bits corresponding to munmapped regions. Is this worth it? And a maybe-silly benefit: if we manage it in the kernel, we could optimize the inevitable case where the bitmap contains pages that are all ones :). If it’s in userspace, KSM could do the, but that will be inefficient at best.
