On Fri, Jul 10, 2026 at 03:03:12PM -0300, Jason Gunthorpe wrote: > On Fri, Jul 10, 2026 at 10:02:55AM -0700, Stanislav Kinsburskii wrote: > > The main customer for this new feature I have in mind is the MSHV driver > > which backs VMs memory with HMM, requires userfaultfd support for > > post-copy live migration and fast restore and it doesn't timeout. > > > > I agree, that this current timeout value used by the other callers might > > not be enough to repopulate the mappings with userfaultfd, but there > > drivers would get -EFAULT for uderfaultfd-backed mappings without this > > change anyway, so getting -EBUSY with the change instead doesn't look > > like a significant change to the behaviour from my POV. > > It sounds like it won't be reliable either then. > > > > So, maybe the deadline should be resetting after every handled fault? > > > ie the timeout really is only about the mmu notifier and we don't > > > count the time spent handling faults or walking? > > > > The timeout was inherited from existing HMM users rather than introduced > > as a new HMM policy. Some GPU drivers use HMM_RANGE_DEFAULT_TIMEOUT as a > > budget for the whole range population operation, including HMM retries > > and subsequent driver mapping work. > > Yes, because we always had a timeout around the notifier because that > scheme can sort of live lock. The timeout was to protect that only, ie > limit the number of notifier retries. > > Expanding the timeout to be outside what is bounded by the notifier > retry is not right, and heavy stuff like mapping should be done after > the hmm side succeeds and the notifiers concluded so they can rely on > normal locking instead. > > This is why I'm suggesting to reset the deadline as hmm makes forward > progress, we really only want to bound the notifier retry loop not > anything else. >
Sure, I'll modify accordingly. Thanks, Stanislav > Jason
