From patchwork Wed Mar 8 01:51:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: zhouxianrong@huawei.com X-Patchwork-Id: 9610187 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E35B3604DD for ; Wed, 8 Mar 2017 02:08:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D4378285AE for ; Wed, 8 Mar 2017 02:08:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C8EF3285B6; Wed, 8 Mar 2017 02:08:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4751E285B6 for ; Wed, 8 Mar 2017 02:08:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756577AbdCHCIn (ORCPT ); Tue, 7 Mar 2017 21:08:43 -0500 Received: from szxga02-in.huawei.com ([45.249.212.188]:3400 "EHLO dggrg02-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1756596AbdCHCIm (ORCPT ); Tue, 7 Mar 2017 21:08:42 -0500 Received: from 172.30.72.56 (EHLO DGGEML401-HUB.china.huawei.com) ([172.30.72.56]) by dggrg02-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id AJO67932; Wed, 08 Mar 2017 09:56:48 +0800 (CST) Received: from shacidculx1372.china.huawei.com (10.143.155.56) by DGGEML401-HUB.china.huawei.com (10.3.17.32) with Microsoft SMTP Server id 14.3.301.0; Wed, 8 Mar 2017 09:56:35 +0800 From: To: CC: , , , , , , , , , , , , , , , Subject: [PATCH] compaction: add def_blk_aops migrate function for memory compaction Date: Wed, 8 Mar 2017 09:51:55 +0800 Message-ID: <1488937915-78955-1-git-send-email-zhouxianrong@huawei.com> X-Mailer: git-send-email 1.7.9.5 MIME-Version: 1.0 X-Originating-IP: [10.143.155.56] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.58BF64E2.0048, 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: f81851985d9ce7e64403a4743a43dff6 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: zhouxianrong the reason for why to do this is based on below 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. Signed-off-by: zhouxianrong --- fs/block_dev.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/block_dev.c b/fs/block_dev.c index 1c62845..9343b60 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -2062,6 +2062,9 @@ static int blkdev_writepages(struct address_space *mapping, .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 \