From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752058AbdCMJvq (ORCPT ); Mon, 13 Mar 2017 05:51:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:44477 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750978AbdCMJvj (ORCPT ); Mon, 13 Mar 2017 05:51:39 -0400 Subject: Re: [RFC] mm/compaction: ignore block suitable after check large free page To: Yisheng Xie , akpm@linux-foundation.org, mhocko@suse.com, mgorman@techsingularity.net, iamjoonsoo.kim@lge.com, rientjes@google.com, minchan@kernel.org References: <1489119648-59583-1-git-send-email-xieyisheng1@huawei.com> <9104271f-c90f-772c-26b2-410fa8bdfdb0@huawei.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, guohanjun@huawei.com, qiuxishi@huawei.com, liubo95@huawei.com From: Vlastimil Babka Message-ID: <129003b1-bf1e-db03-6117-59657d2ae0b1@suse.cz> Date: Mon, 13 Mar 2017 10:51:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <9104271f-c90f-772c-26b2-410fa8bdfdb0@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/10/2017 10:53 AM, Yisheng Xie wrote: > Hi Vlastimil, > > Thanks for comment. > On 2017/3/10 15:30, Vlastimil Babka wrote: >> On 03/10/2017 05:20 AM, Yisheng Xie wrote: >>> If the migrate target is a large free page and we ignore suitable, >>> it may not good for defrag. So move the ignore block suitable after >>> check large free page. >> >> Right. But in practice I expect close to no impact, because direct >> compaction shouldn't have to be called if there's a >=pageblock_order >> page already available. >> > Maybe you are right and this change is just based on logical analyses. I'm not opposing the change, it might be better for future-proofing the function, just pointing out that it most likely won't have any visible effect right now. > Presently, only in direct compaction, we increase the compaction priority, > and ignore suitable at MIN_COMPACT_PRIORITY. I have a silly question, can > we do the similar thing in kcompactd? maybe by doing most work in kcompactd, > we can get better perf of slow path. That would need a very good evaluation at the very least. Migrating pages into pageblocks other than movable ones brings the danger of later unmovable/reclaimable allocations having to fallback to movable pageblocks and causing permanent fragmentation. For direct compaction we decided that it's better to risk permanent fragmentation than a premature OOM, but for kcompactd there doesn't seem to be such compelling reason. > Thanks > Yisheng Xie > >>> Signed-off-by: Yisheng Xie >>> --- >>> mm/compaction.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/mm/compaction.c b/mm/compaction.c >>> index 0fdfde0..4bf2a5d 100644 >>> --- a/mm/compaction.c >>> +++ b/mm/compaction.c >>> @@ -991,9 +991,6 @@ static bool too_many_isolated(struct zone *zone) >>> static bool suitable_migration_target(struct compact_control *cc, >>> struct page *page) >>> { >>> - if (cc->ignore_block_suitable) >>> - return true; >>> - >>> /* If the page is a large free page, then disallow migration */ >>> if (PageBuddy(page)) { >>> /* >>> @@ -1005,6 +1002,9 @@ static bool suitable_migration_target(struct compact_control *cc, >>> return false; >>> } >>> >>> + if (cc->ignore_block_suitable) >>> + return true; >>> + >>> /* If the block is MIGRATE_MOVABLE or MIGRATE_CMA, allow migration */ >>> if (migrate_async_suitable(get_pageblock_migratetype(page))) >>> return true; >>> >> >> >> . >> >