From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756126Ab1EQRwX (ORCPT ); Tue, 17 May 2011 13:52:23 -0400 Received: from smtp107.prem.mail.ac4.yahoo.com ([76.13.13.46]:28865 "HELO smtp107.prem.mail.ac4.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1756041Ab1EQRwT (ORCPT ); Tue, 17 May 2011 13:52:19 -0400 X-Yahoo-SMTP: _Dag8S.swBC1p4FJKLCXbs8NQzyse1SYSgnAbY0- X-YMail-OSG: pLmYH24VM1nJss40U5eXItTNnGHQ2AcglZnTLVAIeWxo_Hi ssMgfQhjGAZDnterWtoQHhQNkNuljLavMrHmk1J.w8uDOV6Q1Sk9ipBi6Qm1 uK7tIt_6Nw8fw_2S5DcuNvcGRX4fzJxLR1TRV37WKkJHbgix8256gBRkR8vp vgCvyU.UbzgRv4nuAYO8iFsAAO63_7o7Nh_cXV7qkzIq.sY3xn1HAbSQmJvC v1uj1q70DN13n44vv3MNPgKtQuhL5YcCDHEkfcTY3oY0la5H.adIXNVJxtMS a9PPU3er71iUYyoFjpfhBuwo1zaXrYn3UZn3esLix.6sXhyLebYxcr2OUugZ Jm3j0uBDqKd4158iJaeImW9zT X-Yahoo-Newman-Property: ymail-3 Date: Tue, 17 May 2011 12:52:14 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@router.home To: Mel Gorman cc: David Rientjes , Andrew Morton , James Bottomley , Colin King , Raghavendra D Prabhu , Jan Kara , Chris Mason , Pekka Enberg , Rik van Riel , Johannes Weiner , linux-fsdevel , linux-mm , linux-kernel , linux-ext4 Subject: Re: [PATCH 3/4] mm: slub: Do not take expensive steps for SLUBs speculative high-order allocations In-Reply-To: <20110517162256.GO5279@suse.de> Message-ID: References: <1305295404-12129-1-git-send-email-mgorman@suse.de> <1305295404-12129-4-git-send-email-mgorman@suse.de> <20110517084227.GI5279@suse.de> <20110517162256.GO5279@suse.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 17 May 2011, Mel Gorman wrote: > > That is not what I meant. I would like more higher order allocations to > > succeed. That does not mean that slubs allocation methods and flags passed > > have to stay the same. You can change the slub behavior if it helps. > > > > In this particular patch, the success rate for high order allocations > would likely decrease in low memory conditions albeit the latency when > calling the page allocator will be lower and the disruption to the > system will be less (no copying or reclaim of pages). My expectation > would be that it's cheaper for SLUB to fall back than compact memory > or reclaim pages even if this means a slab page is smaller until more > memory is free. However, if the "goodness" criteria is high order > allocation success rate, the patch shouldn't be merged. The criteria is certainly overall system performance and not a high order allocation rate. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Lameter Subject: Re: [PATCH 3/4] mm: slub: Do not take expensive steps for SLUBs speculative high-order allocations Date: Tue, 17 May 2011 12:52:14 -0500 (CDT) Message-ID: References: <1305295404-12129-1-git-send-email-mgorman@suse.de> <1305295404-12129-4-git-send-email-mgorman@suse.de> <20110517084227.GI5279@suse.de> <20110517162256.GO5279@suse.de> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: David Rientjes , Andrew Morton , James Bottomley , Colin King , Raghavendra D Prabhu , Jan Kara , Chris Mason , Pekka Enberg , Rik van Riel , Johannes Weiner , linux-fsdevel , linux-mm , linux-kernel , linux-ext4 To: Mel Gorman Return-path: In-Reply-To: <20110517162256.GO5279@suse.de> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 17 May 2011, Mel Gorman wrote: > > That is not what I meant. I would like more higher order allocations to > > succeed. That does not mean that slubs allocation methods and flags passed > > have to stay the same. You can change the slub behavior if it helps. > > > > In this particular patch, the success rate for high order allocations > would likely decrease in low memory conditions albeit the latency when > calling the page allocator will be lower and the disruption to the > system will be less (no copying or reclaim of pages). My expectation > would be that it's cheaper for SLUB to fall back than compact memory > or reclaim pages even if this means a slab page is smaller until more > memory is free. However, if the "goodness" criteria is high order > allocation success rate, the patch shouldn't be merged. The criteria is certainly overall system performance and not a high order allocation rate. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org