Sounds good.
On 2017-06-16 15:44, Rob Clark wrote:
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
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? Or change it's name to
> ms
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...?
I
On Thu, Jun 15, 2017 at 5:59 PM, Susheelendra, Sushmita
wrote:
> 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
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
purg
