From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, vbabka@suse.cz, daniel@ffwll.ch,
ray.huang@amd.com
Subject: Re: [PATCH 2/2] drm/ttm: optimize the pool shrinker a bit v2
Date: Mon, 26 Apr 2021 13:15:13 +0200 [thread overview]
Message-ID: <51fe2c43-4f05-5727-1680-b6907d652630@gmail.com> (raw)
In-Reply-To: <57572373-d68c-80de-7f9e-c04239d1b050@gmail.com>
Just a gentle ping?
Are you ok with this explanation Andrew or should I look for a different
approach?
Thanks,
Christian.
Am 16.04.21 um 09:08 schrieb Christian König:
> Am 15.04.21 um 22:33 schrieb Andrew Morton:
>> On Thu, 15 Apr 2021 13:56:24 +0200 "Christian König"
>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>
>>> @@ -530,6 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
>>> for (j = 0; j < MAX_ORDER; ++j)
>>> ttm_pool_type_fini(&pool->caching[i].orders[j]);
>>> }
>>> +
>>> + /* We removed the pool types from the LRU, but we need to also
>>> make sure
>>> + * that no shrinker is concurrently freeing pages from the pool.
>>> + */
>>> + sync_shrinkers();
>> It isn't immediately clear to me how this works. ttm_pool_fini() has
>> already freed all the pages hasn't it? So why would it care if some
>> shrinkers are still playing with the pages?
>
> Yes ttm_pool_fini() has freed up all pages which had been in the pool
> when the function was called.
>
> But the problem is it is possible that a parallel running shrinker has
> taken a page from the pool and is in the process of freeing it up.
>
> When I return here the pool structure and especially the device
> structure are freed while the parallel running shrinker is still using
> them.
>
> I could go for a design where we have one shrinker per device instead,
> but that would put a bit to much pressure on the pool in my opinion.
>
>> Or is it the case that ttm_pool_fini() is assuming that there will be
>> some further action against these pages, which requires that shrinkers
>> no longer be accessing the pages and which further assumes that future
>> shrinker invocations will not be able to look up these pages?
>>
>> IOW, a bit more explanation about the dynamics here would help!
>
> Sorry, I'm not a native speaker of English and sometimes still have a
> hard time explaining things.
>
> Regards,
> Christian.
next prev parent reply other threads:[~2021-04-26 11:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-15 11:56 [PATCH 1/2] mm/vmscan: add sync_shrinkers function Christian König
2021-04-15 11:56 ` [PATCH 2/2] drm/ttm: optimize the pool shrinker a bit v2 Christian König
2021-04-15 20:33 ` Andrew Morton
2021-04-16 7:08 ` Christian König
2021-04-26 11:15 ` Christian König [this message]
2021-04-15 13:23 ` [PATCH 1/2] mm/vmscan: add sync_shrinkers function Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51fe2c43-4f05-5727-1680-b6907d652630@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ray.huang@amd.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox