Quoting Michal Hocko (2018-06-22 16:02:42)
Hi, this is an RFC and not tested at all. I am not very familiar with the mmu notifiers semantics very much so this is a crude attempt to achieve what I need basically. It might be completely wrong but I would like to discuss what would be a better way if that is the case.
get_maintainers gave me quite large list of people to CC so I had to trim it down. If you think I have forgot somebody, please let me know
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c index 854bd51b9478..5285df9331fa 100644 --- a/drivers/gpu/drm/i915/i915_gem_userptr.c +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object *mo) mo->attached = false; }
-static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn, +static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn, struct mm_struct *mm, unsigned long start,
unsigned long end)
unsigned long end,bool blockable){ struct i915_mmu_notifier *mn = container_of(_mn, struct i915_mmu_notifier, mn); @@ -124,7 +125,7 @@ static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn, LIST_HEAD(cancelled);
if (RB_EMPTY_ROOT(&mn->objects.rb_root))
return;
return 0;
The principle wait here is for the HW (even after fixing all the locks to be not so coarse, we still have to wait for the HW to finish its access). The first pass would be then to not do anything here if !blockable.
Jerome keeps on shaking his head and telling us we're doing it all wrong, so maybe it'll all fall out of HMM before we have to figure out how to differentiate between objects that can be invalidated immediately and those that need to acquire locks and/or wait. -Chris