[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210216182242.GJ2858050@casper.infradead.org>
Date: Tue, 16 Feb 2021 18:22:42 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Minchan Kim <minchan@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-mm <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>, cgoldswo@...eaurora.org,
linux-fsdevel@...r.kernel.org, mhocko@...e.com, david@...hat.com,
vbabka@...e.cz, viro@...iv.linux.org.uk, joaodias@...gle.com
Subject: Re: [RFC 1/2] mm: disable LRU pagevec during the migration
temporarily
On Tue, Feb 16, 2021 at 09:03:47AM -0800, Minchan Kim wrote:
> LRU pagevec holds refcount of pages until the pagevec are drained.
> It could prevent migration since the refcount of the page is greater
> than the expection in migration logic. To mitigate the issue,
> callers of migrate_pages drains LRU pagevec via migrate_prep or
> lru_add_drain_all before migrate_pages call.
>
> However, it's not enough because pages coming into pagevec after the
> draining call still could stay at the pagevec so it could keep
> preventing page migration. Since some callers of migrate_pages have
> retrial logic with LRU draining, the page would migrate at next trail
> but it is still fragile in that it doesn't close the fundamental race
> between upcoming LRU pages into pagvec and migration so the migration
> failure could cause contiguous memory allocation failure in the end.
Have you been able to gather any numbers on this? eg does migration
now succeed 5% more often?
Powered by blists - more mailing lists