Hi, Dave On Fri, 2024-02-16 at 12:58 +1000, Dave Airlie wrote: > On Thu, 15 Feb 2024 at 20:06, Tvrtko Ursulin > <tvrtko.ursu...@linux.intel.com> wrote: > > > > Hi Dave, Daniel, > > > > First pull request for 6.9 with probably one more coming in one to > > two > > weeks. > > > > Nothing to interesting in this one, mostly a sprinkle of small > > fixes in > > GuC, HuC, Perf/OA, a tiny bit of prep work for future platforms and > > some > > code cleanups. > > > > One new uapi in the form of a GuC submission version query which > > Mesa > > wants for implementing Vulkan async compute queues. > > > > Regards, > > > > Tvrtko > > > > drm-intel-gt-next-2024-02-15: > > UAPI Changes: > > > > - Add GuC submission interface version query (Tvrtko Ursulin) > > > > Driver Changes: > > > > Fixes/improvements/new stuff: > > > > - Atomically invalidate userptr on mmu-notifier (Jonathan Cavitt) > > I've pulled this, but the above patch is triggering my this seems > wrong spider sense. > > This and probably the preceeding patch that this references seem to > move i915 to a long term pinning of userptr in memory with what I can > see no accounting, and away from what the desired behaviour for > drivers should be.
I can only answer for the first patch there, It was some time ago it was written, but at that point the pinning was held both by get_pages() and by submission. I removed the submission pinning and instead moved get_pages() to start of submission. So no significant change in pinning time there. For some reason I can't clearly remember the submission pinning got in the way of the vm_bind implementation. That said, the pinning AFAIR is released in the gem shrinker. And it's different from what other drivers are doing. i915 never got to the point where it completely dropped the pinning after the binding. /Thomas > > It also feels like the authorship on this might be lies which also > worries me. > > Dave.
