[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1466112375-1717-1-git-send-email-richard@nod.at>
Date: Thu, 16 Jun 2016 23:26:12 +0200
From: Richard Weinberger <richard@....at>
To: linux-mm@...ck.org
Cc: linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
hannes@...xchg.org, mgorman@...hsingularity.net,
n-horiguchi@...jp.nec.com, mhocko@...e.com,
kirill.shutemov@...ux.intel.com, hughd@...gle.com, vbabka@...e.cz,
akpm@...ux-foundation.org, adrian.hunter@...el.com,
dedekind1@...il.com, richard@....at, hch@...radead.org,
linux-fsdevel@...r.kernel.org, boris.brezillon@...e-electrons.com,
maxime.ripard@...e-electrons.com, david@...ma-star.at,
david@...morbit.com, alex@...tthing.co, sasha.levin@...cle.com,
iamjoonsoo.kim@....com, rvaswani@...eaurora.org,
tony.luck@...el.com, shailendra.capricorn@...il.com
Subject: Remove page migration fallback (was: UBIFS and page migration)
During page migrations UBIFS gets confused. We triggered this by using CMA
on two different targets.
It turned out that fallback_migrate_page() is not suitable for UBIFS as it
does not copy the PagePrivate flag. Non-trivial block based filesystems
do not notice since they can use buffer_migrate_page().
UBIFS is using this flag among with PageChecked to account free space.
In order to address this issue implement a convenient ->migratepage()
function for UBIFS and disable the automatic assignment of
fallback_migrate_page(). Filesystems maintains should decide themselves
whether they have to implement ->migratepage() or can use the generic function.
Another interesting topic is testing ->migratepage(). So far the only reliable
test to trigger the UBIFS issue we have is real hardware and CMA.
I was able to trigger it a few times in KVM using the migrate_pages() system call.
But not reliable at all.
Thanks,
//richard
[PATCH 1/3] mm: Don't blindly assign fallback_migrate_page()
[PATCH 2/3] mm: Export migrate_page_move_mapping and
[PATCH 3/3] UBIFS: Implement ->migratepage()
Powered by blists - more mailing lists