On 03/09/2017 12:55 AM, a...@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 <zhouxianr...@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-zhouxianr...@huawei.com > Signed-off-by: zhouxianrong <zhouxianr...@huawei.com> > Cc: Kirill A. Shutemov <kirill.shute...@linux.intel.com> > Cc: Johannes Weiner <han...@cmpxchg.org> > Cc: Minchan Kim <minc...@kernel.org> > Cc: Mel Gorman <mgor...@techsingularity.net> > Cc: Vlastimil Babka <vba...@suse.cz> > Cc: Al Viro <v...@zeniv.linux.org.uk> > Cc: <mi.sophia.w...@huawei.com> > Cc: <zhoux...@huawei.com> > Cc: <weidu...@huawei.com> > Cc: <zhangshimi...@huawei.com> > Cc: <won.ho.p...@huawei.com> > Cc: <zhouxiaoy...@huawei.com> > Signed-off-by: Andrew Morton <a...@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 zhouxianr...@huawei.com are > > compaction-add-def_blk_aops-migrate-function-for-memory-compaction.patch >
