On Mon, Jun 10, 2019 at 3:59 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > > 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. Updating legacy bitmap in user space from kernel requires long q; get_user(q, ...); q |= mask; put_user(q, ...); instead of *p |= mask; get_user + put_user was quite slow when we tried before. -- H.J.
