Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752179AbdGDLYW (ORCPT ); Tue, 4 Jul 2017 07:24:22 -0400 Received: from mx2.suse.de ([195.135.220.15]:48570 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751910AbdGDLYV (ORCPT ); Tue, 4 Jul 2017 07:24:21 -0400 Date: Tue, 4 Jul 2017 13:24:14 +0200 From: Michal Hocko To: zhouxianrong Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, vbabka@suse.cz, alexander.h.duyck@intel.com, mgorman@suse.de, l.stach@pengutronix.de, vdavydov.dev@gmail.com, hannes@cmpxchg.org, minchan@kernel.org, npiggin@gmail.com, kirill.shutemov@linux.intel.com, gi-oh.kim@profitbricks.com, luto@kernel.org, keescook@chromium.org, mark.rutland@arm.com, mingo@kernel.org, heiko.carstens@de.ibm.com, iamjoonsoo.kim@lge.com, rientjes@google.com, ming.ling@spreadtrum.com, jack@suse.cz, ebru.akagunduz@gmail.com, bigeasy@linutronix.de, Mi.Sophia.Wang@huawei.com, zhouxiyu@huawei.com, weidu.du@huawei.com, fanghua3@huawei.com, won.ho.park@huawei.com Subject: Re: [PATCH mm] introduce reverse buddy concept to reduce buddy fragment Message-ID: <20170704112414.GA14727@dhcp22.suse.cz> References: <1498821941-55771-1-git-send-email-zhouxianrong@huawei.com> <20170703074829.GD3217@dhcp22.suse.cz> <20170703153307.GA11848@dhcp22.suse.cz> <5c9cf499-6f71-6dda-6378-7e9f27e6cd70@huawei.com> <20170704065215.GB12068@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1068 Lines: 22 On Tue 04-07-17 16:04:52, zhouxianrong wrote: > every 2s i sample /proc/buddyinfo in the whole test process. > > the last about 90 samples were sampled after the test was done. I've tried to explain to you that numbers without a proper testing metodology and highlevel metrics you are interested in and comparision to the base kernel are meaningless. I cannot draw any conclusion from looking at numbers you have posted. Are high order allocations cheaper to do with this patch? What about an averge order-0 allocation request? You are touching memory allocator hot paths and those are really sensitive to changes. It takes a lot of testing with different workloads to prove that no new regressions are introduced. That being said, I completely agree that reducing the memory fragmentation is an important objective but touching the page allocator and adding new branches there sounds like a problematic approach which would have to show _huge_ benefits to be mergeable. Is it possible to improve khugepaged to accomplish the same thing? -- Michal Hocko SUSE Labs