Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932191AbdCILwE (ORCPT ); Thu, 9 Mar 2017 06:52:04 -0500 Received: from szxga02-in.huawei.com ([45.249.212.188]:3856 "EHLO dggrg02-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1753158AbdCILwC (ORCPT ); Thu, 9 Mar 2017 06:52:02 -0500 Subject: Re: + compaction-add-def_blk_aops-migrate-function-for-memory-compaction.patch added to -mm tree To: Vlastimil Babka , , , , , , , , , , , , , , Jan Kara , Hugh Dickins , Linux-FSDevel , LKML References: <58c099dc.qZs+2fQBHcULYdhi%akpm@linux-foundation.org> <6867e5fe-b67e-fe01-4cc4-8338b4043577@suse.cz> From: zhouxianrong Message-ID: <23e36637-8ca0-303c-108d-a06230d3d058@huawei.com> Date: Thu, 9 Mar 2017 19:50:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <6867e5fe-b67e-fe01-4cc4-8338b4043577@suse.cz> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.142.145.228] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58C14186.00D3,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d329bfb8b5738a26c15c521758757087 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4326 Lines: 107 On 2017/3/9 15:58, Vlastimil Babka wrote: > 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 >> 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? I could not find out differences for different disks in block device filesystem; they should behave consistently in block device filesystem layer. for a page of file /dev/block/xxx, when we migrate it, i think it has no difference just like ext4 file migration. but i dare not to say yes. i hope more peoples give their suggestions. > >> Link: http://lkml.kernel.org/r/1488937915-78955-1-git-send-email-zhouxianrong@huawei.com >> Signed-off-by: zhouxianrong >> Cc: Kirill A. Shutemov >> Cc: Johannes Weiner >> Cc: Minchan Kim >> Cc: Mel Gorman >> Cc: Vlastimil Babka >> Cc: Al Viro >> Cc: >> Cc: >> Cc: >> Cc: >> Cc: >> Cc: >> Signed-off-by: Andrew Morton >> --- >> >> 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 >> > > > . >