linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Vlastimil Babka <vbabka@suse.cz>, linux-kernel@vger.kernel.org
Cc: kernel-team@fb.com, akpm@linux-foundation.org,
	linux-mm@kvack.org,  mhocko@kernel.org,
	mgorman@techsingularity.net, rientjes@google.com,
	 aarcange@redhat.com
Subject: Re: [PATCH 2/2] mm,thp,compaction,cma: allow THP migration for CMA allocations
Date: Wed, 26 Feb 2020 12:53:16 -0500	[thread overview]
Message-ID: <bd867dba881347a21757fba908f48a6e23e72439.camel@surriel.com> (raw)
In-Reply-To: <81c8d2fa-a8ae-82b8-f359-bba055fbff68@suse.cz>

[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]

On Wed, 2020-02-26 at 10:48 +0100, Vlastimil Babka wrote:
> On 2/25/20 7:44 PM, Rik van Riel wrote:
> > > Also PageTransHuge() is basically just a PageHead() so for each
> > > non-hugetlbfs compound page this will assume it's a THP, while
> > > correctly
> > > it should reach the __PageMovable() || PageLRU(page) tests below.
> > > 
> > > So probably this should do something like.
> > > 
> > > if (PageHuge(page) || PageTransCompound(page)) {
> > > ...
> > >    if (PageHuge(page) && !hpage_migration_supported)) return
> > > page.
> > 
> > So far so good.
> > 
> > >    if (!PageLRU(head) && !__PageMovable(head)) return page
> > 
> > I don't get this one, though. What about a THP that has
> > not made it onto the LRU list yet for some reason?
> 
> Uh, is it any different from base pages which have to pass the same
> check? I
> guess the caller could do e.g. lru_add_drain_all() first.

You are right, it is not different.

As for lru_add_drain_all(), I wonder at what point that
should happen?

It appears that the order in which things are done does
not really provide a good moment:
1) decide to attempt allocating a range of memory
2) scan each page block for unmovable pages
3) if no unmovable pages are found, mark the page block
   MIGRATE_ISOLATE

I wonder if we should do things the opposite way, first
marking the page block MIGRATE_ISOLATE (to prevent new
allocations), then scanning it, and calling lru_add_drain_all
if we encounter a page that looks like it could benefit from
that.

If we still see unmovable pages after that, it is cheap
enough to set the page block back to its previous state.

> > I don't think anonymous pages are marked __PageMovable,
> > are they? It looks like they only have the PAGE_MAPPING_ANON
> > flag set, not the PAGE_MAPPING_MOVABLE one.
> > 
> > What am I missing?
> 
> My point is that we should not accept compound pages that are neither
> a
> migratable hugetlbfs page nor a THP, as movable.

I have merged your suggestions into my code base. Thank
you for pointing out that 4kB pages have the exact same
restrictions as THPs, and why.

I'll run some tests and will post v2 of the series soon.

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-02-26 17:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-21 21:53 [PATCH 0/2] fix THP migration for CMA allocations Rik van Riel
2020-02-21 21:53 ` [PATCH 1/2] mm,compaction,cma: add alloc_contig flag to compact_control Rik van Riel
2020-02-24 15:04   ` Vlastimil Babka
2020-02-21 21:53 ` [PATCH 2/2] mm,thp,compaction,cma: allow THP migration for CMA allocations Rik van Riel
2020-02-21 22:31   ` Zi Yan
2020-02-21 22:35     ` Rik van Riel
2020-02-24 15:29   ` Vlastimil Babka
2020-02-25 18:44     ` Rik van Riel
2020-02-26  9:48       ` Vlastimil Babka
2020-02-26 17:53         ` Rik van Riel [this message]
2020-02-28 15:17           ` Vlastimil Babka
2020-03-01  2:24             ` Rik van Riel

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=bd867dba881347a21757fba908f48a6e23e72439.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=rientjes@google.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;
as well as URLs for NNTP newsgroup(s).