From: Vlastimil Babka <vbabka@suse.cz>
To: akpm@linux-foundation.org, zhouxianrong@huawei.com,
Mi.Sophia.Wang@huawei.com, hannes@cmpxchg.org,
kirill.shutemov@linux.intel.com, mgorman@techsingularity.net,
minchan@kernel.org, viro@zeniv.linux.org.uk, weidu.du@huawei.com,
won.ho.park@huawei.com, zhangshiming5@huawei.com,
zhouxiaoyan1@huawei.com, zhouxiyu@huawei.com,
mm-commits@vger.kernel.org, Jan Kara <jack@suse.cz>,
Hugh Dickins <hughd@google.com>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: + compaction-add-def_blk_aops-migrate-function-for-memory-compaction.patch added to -mm tree
Date: Thu, 9 Mar 2017 08:58:45 +0100 [thread overview]
Message-ID: <6867e5fe-b67e-fe01-4cc4-8338b4043577@suse.cz> (raw)
In-Reply-To: <58c099dc.qZs+2fQBHcULYdhi%akpm@linux-foundation.org>
On 03/09/2017 12:55 AM, akpm@linux-foundation.org wrote:
>
> The patch titled
> Subject: compaction: add def_blk_aops migrate function for memory compaction
> has been added to the -mm tree. Its filename is
> compaction-add-def_blk_aops-migrate-function-for-memory-compaction.patch
>
> This patch should soon appear at
> http://ozlabs.org/~akpm/mmots/broken-out/compaction-add-def_blk_aops-migrate-function-for-memory-compaction.patch
> and later at
> http://ozlabs.org/~akpm/mmotm/broken-out/compaction-add-def_blk_aops-migrate-function-for-memory-compaction.patch
>
> Before you just go and hit "reply", please:
> a) Consider who else should be cc'ed
> b) Prefer to cc a suitable mailing list as well
> c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> ------------------------------------------------------
> From: zhouxianrong <zhouxianrong@huawei.com>
> Subject: compaction: add def_blk_aops migrate function for memory compaction
That's not really a mm/compaction patch, but a block layer/migration patch. I
don't know internals of those so well, so I added some CC's.
> The reason for doing this is based on two factors.
>
> 1. larg file read/write operations with order 0 can fragmentize
> memory rapidly.
>
> 2. when a special filesystem does not supply migratepage callback,
> kernel would fallback to default function fallback_migrate_page.
> but fallback_migrate_page could not migrate diry page nicely;
> specially kcompactd with MIGRATE_SYNC_LIGHT could not migrate
> diry pages due to this until clear_page_dirty_for_io in some
> procedure. i think it is not suitable here in this scenario.
> for dirty pages we should migrate it rather than skip or writeout
> it in kcomapctd with MIGRATE_SYNC_LIGHT. i think this problem is
> for all filesystem without migratepage not only for block device fs.
>
> So for compaction under large file writing supply migratepage for
> def_blk_aops.
Is this really safe to do? buffer_migrate_page() has some assumptions listed in
its comment (and maybe more that are not listed). Do we know it's safe to use it
for all def_blk_aops users?
> Link: http://lkml.kernel.org/r/1488937915-78955-1-git-send-email-zhouxianrong@huawei.com
> Signed-off-by: zhouxianrong <zhouxianrong@huawei.com>
> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Minchan Kim <minchan@kernel.org>
> Cc: Mel Gorman <mgorman@techsingularity.net>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: <Mi.Sophia.Wang@huawei.com>
> Cc: <zhouxiyu@huawei.com>
> Cc: <weidu.du@huawei.com>
> Cc: <zhangshiming5@huawei.com>
> Cc: <won.ho.park@huawei.com>
> Cc: <zhouxiaoyan1@huawei.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> fs/block_dev.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff -puN fs/block_dev.c~compaction-add-def_blk_aops-migrate-function-for-memory-compaction fs/block_dev.c
> --- a/fs/block_dev.c~compaction-add-def_blk_aops-migrate-function-for-memory-compaction
> +++ a/fs/block_dev.c
> @@ -2064,6 +2064,9 @@ static const struct address_space_operat
> .releasepage = blkdev_releasepage,
> .direct_IO = blkdev_direct_IO,
> .is_dirty_writeback = buffer_check_dirty_writeback,
> +#ifdef CONFIG_MIGRATION
> + .migratepage = buffer_migrate_page,
> +#endif
> };
>
> #define BLKDEV_FALLOC_FL_SUPPORTED \
> _
>
> Patches currently in -mm which might be from zhouxianrong@huawei.com are
>
> compaction-add-def_blk_aops-migrate-function-for-memory-compaction.patch
>
next parent reply other threads:[~2017-03-09 8:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <58c099dc.qZs+2fQBHcULYdhi%akpm@linux-foundation.org>
2017-03-09 7:58 ` Vlastimil Babka [this message]
2017-03-09 11:50 ` zhouxianrong
2017-03-09 12:15 ` Jan Kara
2017-03-09 13:19 ` Michal Hocko
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=6867e5fe-b67e-fe01-4cc4-8338b4043577@suse.cz \
--to=vbabka@suse.cz \
--cc=Mi.Sophia.Wang@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=minchan@kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=weidu.du@huawei.com \
--cc=won.ho.park@huawei.com \
--cc=zhangshiming5@huawei.com \
--cc=zhouxianrong@huawei.com \
--cc=zhouxiaoyan1@huawei.com \
--cc=zhouxiyu@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®