On Sun, Jun 19, 2022 at 10:53:03AM -0700, Rob Clark wrote:
> On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
> <dmitry.osipe...@collabora.com> wrote:
> > + mutex_unlock(&gem_shrinker->lock);
>
> As I mentioned on other thread, count_objects, being approximate but
> lockless and fast is the important thing. Otherwise when you start
> hitting the shrinker on many threads, you end up serializing them all,
> even if you have no pages to return to the system at that point.
Yeah agreed, seems like I was wrong here :-) Atomic counter or something
would also be in link the the lru_list stuff.
It would be to record this in the kerneldoc for the shrinker structure
though, to make sure this is all understood.
> > + /* prevent racing with the dma-buf importing/exporting */
> > + if (!mutex_trylock(&gem_shrinker->dev->object_name_lock)) {
> > + *lock_contention |= true;
> > + goto resv_unlock;
> > + }
>
> I'm not sure this is a good idea to serialize on object_name_lock.
> Purgeable buffers should never be shared (imported or exported). So
> at best you are avoiding evicting and immediately swapping back in, in
> a rare case, at the cost of serializing multiple threads trying to
> reclaim pages in parallel.
Yeah this sounds really bad. Plus this is a per-device lock, and doing
those with trylock means the shrinker will fail to find shrinkable memory
way too often. We need to engineer this out somehow.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
