From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Matthew Wilcox <willy@infradead.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Linux MM <linux-mm@kvack.org>,
amd-gfx list <amd-gfx@lists.freedesktop.org>,
Dave Chinner <dchinner@redhat.com>, Leo Liu <Leo.Liu@amd.com>
Subject: Re: [PATCH] drm/ttm: stop warning on TT shrinker failure
Date: Tue, 23 Mar 2021 14:06:25 +0100 [thread overview]
Message-ID: <20808d08-b66c-13c3-f672-ebce216b2fa2@gmail.com> (raw)
In-Reply-To: <YFng9qXM3NdrGHTx@dhcp22.suse.cz>
Am 23.03.21 um 13:37 schrieb Michal Hocko:
> On Tue 23-03-21 13:21:32, Christian König wrote:
>> Am 23.03.21 um 13:04 schrieb Michal Hocko:
>>> On Tue 23-03-21 12:48:58, Christian König wrote:
>>>> Am 23.03.21 um 12:28 schrieb Daniel Vetter:
>>>>> On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote:
>>>>>> On Mon 22-03-21 20:34:25, Christian König wrote:
>>> [...]
>>>>>>> My only concern is that if I could rely on memalloc_no* being used we could
>>>>>>> optimize this quite a bit further.
>>>>>> Yes you can use the scope API and you will be guaranteed that _any_
>>>>>> allocation from the enclosed context will inherit GFP_NO* semantic.
>>>> The question is if this is also guaranteed the other way around?
>>>>
>>>> In other words if somebody calls get_free_page(GFP_NOFS) are the context
>>>> flags set as well?
>>> gfp mask is always restricted in the page allocator. So say you have
>>> noio scope context and call get_free_page/kmalloc(GFP_NOFS) then the
>>> scope would restrict the allocation flags to GFP_NOIO (aka drop
>>> __GFP_IO). For further details, have a look at current_gfp_context
>>> and its callers.
>>>
>>> Does this answer your question?
>> But what happens if you don't have noio scope and somebody calls
>> get_free_page(GFP_NOFS)?
> Then this will be a regular NOFS request. Let me repeat scope API will
> further restrict any requested allocation mode.
Ok, got it.
>
>> Is then the noio scope added automatically? And is it possible that the
>> shrinker gets called without noio scope even we would need it?
> Here you have lost me again.
>
>>>>>> I think this is where I don't get yet what Christian tries to do: We
>>>>>> really shouldn't do different tricks and calling contexts between direct
>>>>>> reclaim and kswapd reclaim. Otherwise very hard to track down bugs are
>>>>>> pretty much guaranteed. So whether we use explicit gfp flags or the
>>>>>> context apis, result is exactly the same.
>>>> Ok let us recap what TTMs TT shrinker does here:
>>>>
>>>> 1. We got memory which is not swapable because it might be accessed by the
>>>> GPU at any time.
>>>> 2. Make sure the memory is not accessed by the GPU and driver need to grab a
>>>> lock before they can make it accessible again.
>>>> 3. Allocate a shmem file and copy over the not swapable pages.
>>> This is quite tricky because the shrinker operates in the PF_MEMALLOC
>>> context so such an allocation would be allowed to completely deplete
>>> memory unless you explicitly mark that context as __GFP_NOMEMALLOC.
>> Thanks, exactly that was one thing I was absolutely not sure about. And yes
>> I agree that this is really tricky.
>>
>> Ideally I would like to be able to trigger swapping out the shmem page I
>> allocated immediately after doing the copy.
> So let me try to rephrase to make sure I understand. You would like to
> swap out the existing content from the shrinker and you use shmem as a
> way to achieve that. The swapout should happen at the time of copying
> (shrinker context) or shortly afterwards?
>
> So effectively to call pageout() on the shmem page after the copy?
Yes, exactly that.
>> This way I would only need a single page for the whole shrink operation at
>> any given time.
> What do you mean by that? You want the share the same shmem page for
> other copy+swapout?
Correct, yes.
The idea is that we can swap out the content of a full GPU buffer object
this way to give the backing store of the object back to the core memory
managment.
Regards,
Christian.
next prev parent reply other threads:[~2021-03-23 13:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210319140857.2262-1-christian.koenig@amd.com>
[not found] ` <YFTk1GSaUDI3wcWt@phenom.ffwll.local>
[not found] ` <2831bfcc-140e-dade-1f50-a6431e495e9d@gmail.com>
[not found] ` <YFT2LSR97rkkPyEP@phenom.ffwll.local>
[not found] ` <1ae415c4-8e49-5183-b44d-bc92088657d5@gmail.com>
[not found] ` <CAKMK7uEDhuvSwJj5CX8vHgLb+5zm=rdJPmXwb-VQWdrW6GwQZw@mail.gmail.com>
[not found] ` <e6e9df3e-cd2b-d80f-205d-6ca1865819b2@gmail.com>
2021-03-22 13:49 ` [PATCH] drm/ttm: stop warning on TT shrinker failure Daniel Vetter
2021-03-22 14:05 ` Matthew Wilcox
2021-03-22 14:22 ` Daniel Vetter
2021-03-22 15:57 ` Michal Hocko
2021-03-22 17:02 ` Daniel Vetter
2021-03-22 19:34 ` Christian König
2021-03-23 7:38 ` Michal Hocko
2021-03-23 11:28 ` Daniel Vetter
2021-03-23 11:46 ` Michal Hocko
2021-03-23 11:51 ` Christian König
2021-03-23 12:00 ` Daniel Vetter
2021-03-23 12:05 ` Michal Hocko
2021-03-23 11:48 ` Christian König
2021-03-23 12:04 ` Michal Hocko
2021-03-23 12:21 ` Christian König
2021-03-23 12:37 ` Michal Hocko
2021-03-23 13:06 ` Christian König [this message]
2021-03-23 13:41 ` Michal Hocko
2021-03-23 13:56 ` Christian König
2021-03-23 15:13 ` Michal Hocko
2021-03-23 15:45 ` Christian König
2021-03-24 10:19 ` Thomas Hellström (Intel)
2021-03-24 11:55 ` Daniel Vetter
2021-03-24 12:00 ` Christian König
2021-03-24 12:01 ` Daniel Vetter
2021-03-24 12:07 ` Christian König
2021-03-24 19:20 ` Daniel Vetter
2021-03-23 13:15 ` Daniel Vetter
2021-03-23 13:48 ` Michal Hocko
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=20808d08-b66c-13c3-f672-ebce216b2fa2@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=Leo.Liu@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dchinner@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).