Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932642AbcLGRfL (ORCPT ); Wed, 7 Dec 2016 12:35:11 -0500 Received: from outbound-smtp02.blacknight.com ([81.17.249.8]:38906 "EHLO outbound-smtp02.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753192AbcLGRfK (ORCPT ); Wed, 7 Dec 2016 12:35:10 -0500 Date: Wed, 7 Dec 2016 17:35:07 +0000 From: Mel Gorman To: Christoph Lameter Cc: Andrew Morton , Michal Hocko , Vlastimil Babka , Johannes Weiner , Jesper Dangaard Brouer , Joonsoo Kim , Linux-MM , Linux-Kernel Subject: Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v7 Message-ID: <20161207173507.abvj3tp3vh6es3yz@techsingularity.net> References: <20161207101228.8128-1-mgorman@techsingularity.net> <20161207155750.yfsizliaoodks5k4@techsingularity.net> <20161207164554.b73qjfxy2w3h3ycr@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: 1307 Lines: 28 On Wed, Dec 07, 2016 at 11:11:08AM -0600, Christoph Lameter wrote: > On Wed, 7 Dec 2016, Mel Gorman wrote: > > > 3.0-era kernels had better fragmentation control, higher success rates at > > allocation etc. I vaguely recall that it had fewer sources of high-order > > allocations but I don't remember specifics and part of that could be the > > lack of THP at the time. The overhead was massive due to massive stalls > > and excessive reclaim -- hours to complete some high-allocation stress > > tests even if the success rate was high. > > There were a couple of high order page reclaim improvements implemented > at that time that were later abandoned. I think higher order pages were > more available than now. There were, the cost was high -- lumpy reclaim was a major source of the cost but not the only one. The cost of allocation offset any benefit of having them. At least for hugepages it did, I don't know about SLUB because I didn't quantify if the benefit of SLUB using huge pages was offset by the allocation cost (I doubt it). The cost later became intolerable when THP started hitting those paths routinely. It's not simply a case of going back to how fragmentation control was managed then because it'll simply reintroduce excessive stalls in allocation paths. -- Mel Gorman SUSE Labs