From: Michal Hocko <mhocko@suse.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.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 13:37:10 +0100 [thread overview]
Message-ID: <YFng9qXM3NdrGHTx@dhcp22.suse.cz> (raw)
In-Reply-To: <75ff80c5-a054-d13d-85c1-0040addb45d2@gmail.com>
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.
> 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?
> 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?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2021-03-23 12:37 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 [this message]
2021-03-23 13:06 ` Christian König
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=YFng9qXM3NdrGHTx@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=Leo.Liu@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dchinner@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-mm@kvack.org \
--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).