On Wed, Jan 4, 2023 at 12:57 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > 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. Yes, soon. amoorthy@xxxxxxxxxx is working on it. Also a small correction regarding userspace needing to track MADV_DONTNEEDs, userfaultfd already handles that with UFFD_EVENT_REMOVE, so it's a non-issue. Even more reason to take the no-slow-GUP approach. - James
