linux-kernel - Re: [PATCH 2/2] mm,thp,compaction,cma: allow THP migration for CMA allocations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Feb 2020 12:53:16 -0500
From:   Rik van Riel <riel@...riel.com>
To:     Vlastimil Babka <vbabka@...e.cz>, linux-kernel@...r.kernel.org
Cc:     kernel-team@...com, akpm@...ux-foundation.org, linux-mm@...ck.org,
        mhocko@...nel.org, mgorman@...hsingularity.net,
        rientjes@...gle.com, aarcange@...hat.com
Subject: Re: [PATCH 2/2] mm,thp,compaction,cma: allow THP migration for CMA
 allocations

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)