On Thu, Jan 30, 2025 at 10:37:06AM +0100, David Hildenbrand wrote: > On 30.01.25 01:27, Alistair Popple wrote: > > On Wed, Jan 29, 2025 at 12:58:02PM +0100, David Hildenbrand wrote: > > > Let's document how this function is to be used, and why the requirement > > > for the folio lock might maybe be dropped in the future. > > > > Sorry, only just catching up on your other thread. The folio lock was to ensure > > the GPU got a chance to make forward progress by mapping the page. Without it > > the CPU could immediately invalidate the entry before the GPU had a chance to > > retry the fault. > > > Obviously performance wise having such thrashing is terrible, so should > > really be avoided by userspace, but the lock at least allowed such programs > > to complete. > > Thanks for the clarification. So it's relevant that the MMU notifier in > remove_device_exclusive_entry() is sent after taking the folio lock. > > However, as soon as we drop the folio lock, remove_device_exclusive_entry() > will become active, lock the folio and trigger the MMU notifier. > > So the time it is actually mapped into the device is rather Looks like you cut off a bit here (or mail transport did that somewhere), but see my other reply I don't think this is a legit use-case. So we don't have to worry. Well beyond documenting that if userspace concurrently thrashes the same page with both device atomics and cpu access it will stall real bad. -Sima -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
