From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751356AbdCMMRO (ORCPT ); Mon, 13 Mar 2017 08:17:14 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:4315 "EHLO dggrg01-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752137AbdCMMRI (ORCPT ); Mon, 13 Mar 2017 08:17:08 -0400 Subject: Re: [RFC] mm/compaction: ignore block suitable after check large free page To: Vlastimil Babka , , , , , , References: <1489119648-59583-1-git-send-email-xieyisheng1@huawei.com> <9104271f-c90f-772c-26b2-410fa8bdfdb0@huawei.com> <129003b1-bf1e-db03-6117-59657d2ae0b1@suse.cz> CC: , , , , From: Yisheng Xie Message-ID: Date: Mon, 13 Mar 2017 20:16:30 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <129003b1-bf1e-db03-6117-59657d2ae0b1@suse.cz> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.29.40] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.58C68DA7.00F9,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: ca408940d783db6877e7fee368091734 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vlastimil, Thanks for comment. On 2017/3/13 17:51, Vlastimil Babka wrote: > 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. Get it, maybe I should put these in the change log :) > >> 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 for kindly explain. > >> Thanks >> Yisheng Xie