On Thu, Dec 08, 2022, James Houghton wrote: > - For the no-slow-GUP choice, if someone MADV_DONTNEEDed memory and we > didn't know about it, we would get stuck in MADV_POPULATE_WRITE. By > using UFFD_FEATURE_THREAD_ID, we can tell if we got a userfault for a > thread that is in the middle of a MADV_POPULATE_WRITE, and we can try > to unblock the thread by doing an extra UFFDIO_CONTINUE. > > - For the PF_NO_UFFD_WAIT choice, if someone MADV_DONTNEEDed memory, > we would just keep trying to start the vCPU without doing anything (we > assume some other thread has UFFDIO_CONTINUEd for us). This is > basically the same as if we were stuck in MADV_POPULATE_WRITE, and we > can try to unblock the thread in a fashion similar to how we would in > the other case. > > So really these approaches have similar requirements for what > userspace needs to track. So I think I prefer the no-slow-GUP approach > then. Are you planning on sending a patch (RFC?) for the no-slow-GUP approach? It sounds like there's a rough consensus that that's a viable, minimally invasive solution.
