Re: [Freedreno] [PATCH] fixup! drm/msm: Separate locking of buffer resources from struct_mutex

On Fri, Jun 16, 2017 at 5:32 PM, wrote: > Hi Rob, > > This looks good to me! > > Just one nit: msm_gem_vunmap becomes very shrinker specific as it holds the > msm_obj->lock with the shrinker class. Should we have the caller i.e. > msm_gem_shrinker_vmap hold it instead?

Re: [Freedreno] [PATCH] fixup! drm/msm: Separate locking of buffer resources from struct_mutex

Hi Rob, This looks good to me! Just one nit: msm_gem_vunmap becomes very shrinker specific as it holds the msm_obj->lock with the shrinker class. Should we have the caller i.e. msm_gem_shrinker_vmap hold it instead? Or change it's name to msm_gem_vunmap_shrinker or something like that...?

[Freedreno] [PATCH] fixup! drm/msm: Separate locking of buffer resources from struct_mutex

--- Ok, 2nd fixup to handle vmap shrinking. drivers/gpu/drm/msm/msm_gem.c | 44 +++ 1 file changed, 36 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index f5d1f84..3190e05 100644 ---

Re: [Freedreno] [PATCH] fixup! drm/msm: Separate locking of buffer resources from struct_mutex

Hi Rob, I can see how we can trigger the shrinker on objB while holding objA->lock. So, the nested lock with class SHRINKER makes sense. However, I’m trying to figure how the get_pages/vmap/fault path on an objA can end up triggering the shrinker on objA itself. As objA itself would not be