[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <af33fa8d3908684df7bac352e037c87a20fb5d3f.camel@surriel.com>
Date: Sat, 29 Feb 2020 21:24:09 -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 Fri, 2020-02-28 at 16:17 +0100, Vlastimil Babka wrote:
> On 2/26/20 6:53 PM, Rik van Riel wrote:
> >
> > 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.
>
> Yeah seems like the whole has_unmovable_pages() thing isn't much
> useful
> here. It might prevent some unnecessary action like isolating
> something,
> then finding non-movable page and rolling back the isolation. But
> maybe
> it's not worth the savings, and also has_unmovable_pages() being
> false
> doesn't guarantee succeed in the actual isolate+migrate attempt. And
> if
> it can cause a false negative due to lru pages not drained, then it's
> actually worse than if it wasn't called at all.
We'll experiment with that, and see how often it is an
issue in practice.
If this aspect of the code needs improving, I suspect
Roman and I will find it soon enough.
--
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists