Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933216AbcK1QVf (ORCPT ); Mon, 28 Nov 2016 11:21:35 -0500 Received: from outbound-smtp06.blacknight.com ([81.17.249.39]:54606 "EHLO outbound-smtp06.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932468AbcK1QV3 (ORCPT ); Mon, 28 Nov 2016 11:21:29 -0500 Date: Mon, 28 Nov 2016 16:21:26 +0000 From: Mel Gorman To: Christoph Lameter Cc: Andrew Morton , Michal Hocko , Vlastimil Babka , Johannes Weiner , Linux-MM , Linux-Kernel Subject: Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v3 Message-ID: <20161128162126.ulbqrslpahg4wdk3@techsingularity.net> References: <20161127131954.10026-1-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1888 Lines: 41 On Mon, Nov 28, 2016 at 09:39:19AM -0600, Christoph Lameter wrote: > On Sun, 27 Nov 2016, Mel Gorman wrote: > > > > > SLUB has been the default small kernel object allocator for quite some time > > but it is not universally used due to performance concerns and a reliance > > on high-order pages. The high-order concerns has two major components -- > > high-order pages are not always available and high-order page allocations > > potentially contend on the zone->lock. This patch addresses some concerns > > about the zone lock contention by extending the per-cpu page allocator to > > cache high-order pages. The patch makes the following modifications > > Note that SLUB will only use high order pages when available and fall back > to order 0 if memory is fragmented. This means that the effect of this > patch is going to gradually vanish as memory becomes more and more > fragmented. > Yes, that's a problem for SLUB with or without this patch. It's always been the case that SLUB relying on high-order pages for performance is problematic. > I think this patch is beneficial but we need to address long term the > issue of memory fragmentation. That is not only a SLUB issue but an > overall problem since we keep on having to maintain lists of 4k memory > blocks in variuos subsystems. And as memory increases these lists are > becoming larger and larger and more difficult to manage. Code complexity > increases and fragility too (look at transparent hugepages). Ultimately we > will need a clean way to manage the allocation and freeing of large > physically contiguous pages. Reserving memory at booting (CMA, giant > pages) is some sort of solution but this all devolves into lots of knobs > that only insiders know how to tune and an overall fragile solution. > While I agree with all of this, it's also a problem independent of this patch. -- Mel Gorman SUSE Labs