From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932178Ab1EQTft (ORCPT ); Tue, 17 May 2011 15:35:49 -0400 Received: from smtp-out.google.com ([216.239.44.51]:54417 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932127Ab1EQTfr (ORCPT ); Tue, 17 May 2011 15:35:47 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; b=Y+zfRhCJeaKY7Kjjj8QrVXwTrLB8b3PNtvkNtnkgtyDkGRmTOHTuTg2ABoR2qhbFEM 2poQ7aG2Lc4Nd+uUBUqg== Date: Tue, 17 May 2011 12:35:32 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Christoph Lameter cc: Mel Gorman , 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: 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 X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 17 May 2011, Christoph Lameter wrote: > > 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. > SLUB definitely depends on these higher order allocations being successful for performance, dropping back to the min order is a last resort as opposed to failing the kmalloc(). If it's the last resort, then it makes sense that we'd want to try both compaction and reclaim while we're already in the page allocator as we go down the slub slowpath. Why not try just a little harder (compaction and/or reclaim) to alloc the cache's preferred order? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with ESMTP id 910278D003B for ; Tue, 17 May 2011 15:36:04 -0400 (EDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p4HJZgXj031459 for ; Tue, 17 May 2011 12:35:42 -0700 Received: from pwj8 (pwj8.prod.google.com [10.241.219.72]) by hpaq6.eem.corp.google.com with ESMTP id p4HJYxRS030581 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 May 2011 12:35:34 -0700 Received: by pwj8 with SMTP id 8so547365pwj.13 for ; Tue, 17 May 2011 12:35:34 -0700 (PDT) Date: Tue, 17 May 2011 12:35:32 -0700 (PDT) From: David Rientjes Subject: Re: [PATCH 3/4] mm: slub: Do not take expensive steps for SLUBs speculative high-order allocations In-Reply-To: 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 Sender: owner-linux-mm@kvack.org List-ID: To: Christoph Lameter Cc: Mel Gorman , 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 On Tue, 17 May 2011, Christoph Lameter wrote: > > 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. > SLUB definitely depends on these higher order allocations being successful for performance, dropping back to the min order is a last resort as opposed to failing the kmalloc(). If it's the last resort, then it makes sense that we'd want to try both compaction and reclaim while we're already in the page allocator as we go down the slub slowpath. Why not try just a little harder (compaction and/or reclaim) to alloc the cache's preferred order? -- 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