From: Vlastimil Babka <vbabka@suse.cz>
To: Richard Weinberger <richard@nod.at>, linux-fsdevel@vger.kernel.org
Cc: linux-mtd@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, boris.brezillon@free-electrons.com,
maxime.ripard@free-electrons.com, david@sigma-star.at,
david@fromorbit.com, dedekind1@gmail.com, alex@nextthing.co,
akpm@linux-foundation.org, sasha.levin@oracle.com,
iamjoonsoo.kim@lge.com, rvaswani@codeaurora.org,
tony.luck@intel.com, shailendra.capricorn@gmail.com,
kirill.shutemov@linux.intel.com, hch@infradead.org,
hughd@google.com, mgorman@techsingularity.net
Subject: Re: UBIFS and page migration (take 2)
Date: Fri, 1 Apr 2016 12:13:33 +0200 [thread overview]
Message-ID: <56FE49CD.1000302@suse.cz> (raw)
In-Reply-To: <1459461513-31765-1-git-send-email-richard@nod.at>
On 03/31/2016 11:58 PM, Richard Weinberger wrote:
> 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.
> UBIFS is using this flag among with PageChecked to account free space.
> One possible solution is implementing a ->migratepage() function in UBIFS
> which does more or less the same as fallback_migrate_page() but also
> copies PagePrivate. I'm not at all sure whether this is they way to go.
> IMHO either page migration should not happen if ->migratepage() is not implement
> or fallback_migrate_page() has to work for all filesystems.
Yes, we could document more thoroughly the expectations of
fallback_migrate_page() and audit the existing users, but still relying on every
new address_space_operations instance to verify them isn't without risk. And I
doubt there can be a default fallback that's guaranteed safe for all filesystems.
> Comments? Flames? :-)
>
> Thanks,
> //richard
>
> [PATCH 1/2] mm: Export migrate_page_move_mapping and
> [PATCH 2/2] UBIFS: Implement ->migratepage()
>
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Richard Weinberger <richard@nod.at>, linux-fsdevel@vger.kernel.org
Cc: linux-mtd@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, boris.brezillon@free-electrons.com,
maxime.ripard@free-electrons.com, david@sigma-star.at,
david@fromorbit.com, dedekind1@gmail.com, alex@nextthing.co,
akpm@linux-foundation.org, sasha.levin@oracle.com,
iamjoonsoo.kim@lge.com, rvaswani@codeaurora.org,
tony.luck@intel.com, shailendra.capricorn@gmail.com,
kirill.shutemov@linux.intel.com, hch@infradead.org,
hughd@google.com, mgorman@techsingularity.net
Subject: Re: UBIFS and page migration (take 2)
Date: Fri, 1 Apr 2016 12:13:33 +0200 [thread overview]
Message-ID: <56FE49CD.1000302@suse.cz> (raw)
In-Reply-To: <1459461513-31765-1-git-send-email-richard@nod.at>
On 03/31/2016 11:58 PM, Richard Weinberger wrote:
> 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.
> UBIFS is using this flag among with PageChecked to account free space.
> One possible solution is implementing a ->migratepage() function in UBIFS
> which does more or less the same as fallback_migrate_page() but also
> copies PagePrivate. I'm not at all sure whether this is they way to go.
> IMHO either page migration should not happen if ->migratepage() is not implement
> or fallback_migrate_page() has to work for all filesystems.
Yes, we could document more thoroughly the expectations of
fallback_migrate_page() and audit the existing users, but still relying on every
new address_space_operations instance to verify them isn't without risk. And I
doubt there can be a default fallback that's guaranteed safe for all filesystems.
> Comments? Flames? :-)
>
> Thanks,
> //richard
>
> [PATCH 1/2] mm: Export migrate_page_move_mapping and
> [PATCH 2/2] UBIFS: Implement ->migratepage()
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-04-01 10:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-31 21:58 UBIFS and page migration (take 2) Richard Weinberger
2016-03-31 21:58 ` Richard Weinberger
2016-03-31 21:58 ` [PATCH 1/2] mm: Export migrate_page_move_mapping and migrate_page_copy Richard Weinberger
2016-03-31 21:58 ` Richard Weinberger
2016-03-31 21:58 ` [PATCH 2/2] UBIFS: Implement ->migratepage() Richard Weinberger
2016-03-31 21:58 ` Richard Weinberger
2016-04-01 10:14 ` Vlastimil Babka
2016-04-01 10:14 ` Vlastimil Babka
2016-04-01 11:21 ` Richard Weinberger
2016-04-01 11:21 ` Richard Weinberger
2016-04-03 0:13 ` kbuild test robot
2016-04-03 0:13 ` kbuild test robot
2016-04-01 10:13 ` Vlastimil Babka [this message]
2016-04-01 10:13 ` UBIFS and page migration (take 2) Vlastimil Babka
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=56FE49CD.1000302@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=alex@nextthing.co \
--cc=boris.brezillon@free-electrons.com \
--cc=david@fromorbit.com \
--cc=david@sigma-star.at \
--cc=dedekind1@gmail.com \
--cc=hch@infradead.org \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mtd@lists.infradead.org \
--cc=maxime.ripard@free-electrons.com \
--cc=mgorman@techsingularity.net \
--cc=richard@nod.at \
--cc=rvaswani@codeaurora.org \
--cc=sasha.levin@oracle.com \
--cc=shailendra.capricorn@gmail.com \
--cc=tony.luck@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.