On Mon, Apr 24, 2023 at 5:54 PM Nadav Amit <nadav.amit@xxxxxxxxx> wrote: > > > > > On Apr 24, 2023, at 5:15 PM, Anish Moorthy <amoorthy@xxxxxxxxxx> wrote: > > > > On Mon, Apr 24, 2023 at 12:44 PM Nadav Amit <nadav.amit@xxxxxxxxx> wrote: > >> > >> > >> > >>> On Apr 24, 2023, at 10:54 AM, Anish Moorthy <amoorthy@xxxxxxxxxx> wrote: > >>> > >>> On Fri, Apr 21, 2023 at 10:40 AM Nadav Amit <nadav.amit@xxxxxxxxx> wrote: > >>>> > >>>> If I understand the problem correctly, it sounds as if the proper solution > >>>> should be some kind of a range-locks. If it is too heavy or the interface can > >>>> be changed/extended to wake a single address (instead of a range), > >>>> simpler hashed-locks can be used. > >>> > >>> Some sort of range-based locking system does seem relevant, although I > >>> don't see how that would necessarily speed up the delivery of faults > >>> to UFFD readers: I'll have to think about it more. > >> > >> Perhaps I misread your issue. Based on the scalability issues you raised, > >> I assumed that the problem you encountered is related to lock contention. > >> I do not know whether your profiled it, but some information would be > >> useful. > > > > No, you had it right: the issue at hand is contention on the uffd wait > > queues. I'm just not sure what the range-based locking would really be > > doing. Events would still have to be delivered to userspace in an > > ordered manner, so it seems to me that each uffd would still need to > > maintain a queue (and the associated contention). > > There are 2 queues. One for the pending faults that were still not reported > to userspace, and one for the faults that we might need to wake up. The second > one can have range locks. > > Perhaps some hybrid approach would be best: do not block on page-faults that > KVM runs into, which would prevent you from the need to enqueue on fault_wqh. Hi Nadav, If we don't block on the page faults that KVM runs into, what are you suggesting that these threads do? 1. If you're saying that we should kick the threads out to userspace and then read the page fault event, then I would say that it's just unnecessary complexity. (Seems like this is what you mean from what you said below.) 2. If you're saying they should busy-wait, then unfortunately we can't afford that. 3. If it's neither of those, could you clarify? > > But I do not know whether the reporting through KVM instead of > userfaultfd-based mechanism is very clean. I think that an IO-uring based > solution, such as the one I proposed before, would be more generic. Actually, > now that I understand better your use-case, you do not need a core to poll > and you would just be able to read the page-fault information from the IO-uring. > > Then, you can report whether the page-fault blocked or not in a flag. This is a fine idea, but I don't think the required complexity is worth it. The memory fault info reporting piece of this series is relatively uncontentious, so let's assume we have it at our disposal. Now, the complexity to make KVM only attempt fast GUP (and EFAULT if it fails) is really minimal. We automatically know that we don't need to WAKE and which address to make ready. Userspace is also able to resolve the fault: UFFDIO_CONTINUE if we haven't already, then MADV_POPULATE_WRITE if we have (forces userspace page tables to be populated if they haven't been, potentially going through userfaultfd to do so, i.e., if UFFDIO_CONTINUE wasn't already done). It sounds like what you're suggesting is something like: 1. KVM attempts fast GUP then slow GUP. 2. In slow GUP, queue a "non-blocking" userfault, but don't go to sleep (return with VM_FAULT_SIGBUS or something). 3. The vCPU thread gets kicked out to userspace with EFAULT (+ fault info if we've enabled it). 4. Read a fault from the userfaultfd or io_uring. 5. Make the page ready, and if it were non-blocking, then don't WAKE. I have some questions/thoughts with this approach: 1. Is io_uring the only way to make reading from a userfaultfd scale? Maybe it's possible to avoid using a wait_queue for "non-blocking" faults, but then we'd need a special read() API specifically to *avoid* the standard fault_pending_wqh queue. Either approach will be quite complex. 2. We'll still need to annotate KVM in the same-ish place to tell userfaultfd that the fault should be non-blocking, but we'll probably *also* need like GUP_USERFAULT_NONBLOCK and/or FAULT_FLAG_USERFAULT_NOBLOCK or something. (UFFD_FEATURE_SIGBUS does not exactly solve this problem either.) 3. If the vCPU thread is getting kicked out to userspace, it seems like there is no way for it to find/read the #pf it generated. This seems problematic. > > > > > With respect to the "sharding" idea, I collected some more runs of the > > self test (full command in [1]). This time I omitted the "-a" flag, so > > that every vCPU accesses a different range of guest memory with its > > own UFFD, and set the number of reader threads per UFFD to 1. > > Just wondering, did you run the benchmark with DONTWAKE? Sounds as if the > wake is not needed. > Anish's selftest only WAKEs when it's necessary[1]. IOW, we only WAKE when we actually read the #pf from the userfaultfd. If we were to WAKE for each fault, we wouldn't get much of a scalability improvement at all (we would still be contending on the wait_queue locks, just not quite as much as before). [1]: https://lore.kernel.org/kvm/20230412213510.1220557-23-amoorthy@xxxxxxxxxx/ Thanks for your insights/suggestions, Nadav. - James
