Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754422AbcJMLOY (ORCPT ); Thu, 13 Oct 2016 07:14:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:52226 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754124AbcJMLOO (ORCPT ); Thu, 13 Oct 2016 07:14:14 -0400 Subject: Re: [RFC PATCH 3/5] mm/page_alloc: stop instantly reusing freed page To: js1304@gmail.com, Andrew Morton References: <1476346102-26928-1-git-send-email-iamjoonsoo.kim@lge.com> <1476346102-26928-4-git-send-email-iamjoonsoo.kim@lge.com> Cc: Johannes Weiner , Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joonsoo Kim From: Vlastimil Babka Message-ID: <44132140-c678-73a2-b747-f04ad0f3d7df@suse.cz> Date: Thu, 13 Oct 2016 12:59:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1476346102-26928-4-git-send-email-iamjoonsoo.kim@lge.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1204 Lines: 23 On 10/13/2016 10:08 AM, js1304@gmail.com wrote: > From: Joonsoo Kim > > Allocation/free pattern is usually sequantial. If they are freed to > the buddy list, they can be coalesced. However, we first keep these freed > pages at the pcp list and try to reuse them until threshold is reached > so we don't have enough chance to get a high order freepage. This reusing > would provide us some performance advantages since we don't need to > get the zone lock and we don't pay the cost to check buddy merging. > But, less fragmentation and more high order freepage would compensate > this overhead in other ways. First, we would trigger less direct > compaction which has high overhead. And, there are usecases that uses > high order page to boost their performance. > > Instantly resuing freed page seems to provide us computational benefit > but the other affects more precious things like as I/O performance and > memory consumption so I think that it's a good idea to weight > later advantage more. Again, there's also cache hotness to consider. And whether the sequential pattern is still real on a system with higher uptime. Should be possible to evaluate with tracepoints?