From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 6923DDDDEE for ; Tue, 18 Nov 2008 10:17:26 +1100 (EST) Subject: Re: Large stack usage in fs code (especially for PPC64) From: Benjamin Herrenschmidt To: Andrew Morton In-Reply-To: <20081117133137.616cf287.akpm@linux-foundation.org> References: <20081117130856.92e41cd3.akpm@linux-foundation.org> <20081117133137.616cf287.akpm@linux-foundation.org> Content-Type: text/plain Date: Tue, 18 Nov 2008 10:17:04 +1100 Message-Id: <1226963824.7178.255.camel@pasglop> Mime-Version: 1.0 Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, rostedt@goodmis.org, linuxppc-dev@ozlabs.org, paulus@samba.org, mingo@elte.hu, Linus Torvalds , tglx@linutronix.de List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > I'd have thought so, but I'm sure we're about to hear how important an > optimisation the smaller stacks are ;) Not sure, I tend to agree that it would make sense to bump our stack to 64K on 64K pages, it's not like we are saving anything and we are probably adding overhead in alloc/dealloc. I'll see what Paul thinks here. > Yup. That being said, the younger me did assert that "this is a neater > implementation anyway". If we can implement those loops without > needing those on-stack temporary arrays then things probably are better > overall. Amen. Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752854AbYKQXRj (ORCPT ); Mon, 17 Nov 2008 18:17:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751630AbYKQXRb (ORCPT ); Mon, 17 Nov 2008 18:17:31 -0500 Received: from gate.crashing.org ([63.228.1.57]:58471 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751468AbYKQXRa (ORCPT ); Mon, 17 Nov 2008 18:17:30 -0500 Subject: Re: Large stack usage in fs code (especially for PPC64) From: Benjamin Herrenschmidt To: Andrew Morton Cc: Linus Torvalds , rostedt@goodmis.org, linux-kernel@vger.kernel.org, paulus@samba.org, linuxppc-dev@ozlabs.org, mingo@elte.hu, tglx@linutronix.de, linux-mm@kvack.org In-Reply-To: <20081117133137.616cf287.akpm@linux-foundation.org> References: <20081117130856.92e41cd3.akpm@linux-foundation.org> <20081117133137.616cf287.akpm@linux-foundation.org> Content-Type: text/plain Date: Tue, 18 Nov 2008 10:17:04 +1100 Message-Id: <1226963824.7178.255.camel@pasglop> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I'd have thought so, but I'm sure we're about to hear how important an > optimisation the smaller stacks are ;) Not sure, I tend to agree that it would make sense to bump our stack to 64K on 64K pages, it's not like we are saving anything and we are probably adding overhead in alloc/dealloc. I'll see what Paul thinks here. > Yup. That being said, the younger me did assert that "this is a neater > implementation anyway". If we can implement those loops without > needing those on-stack temporary arrays then things probably are better > overall. Amen. Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: Large stack usage in fs code (especially for PPC64) From: Benjamin Herrenschmidt In-Reply-To: <20081117133137.616cf287.akpm@linux-foundation.org> References: <20081117130856.92e41cd3.akpm@linux-foundation.org> <20081117133137.616cf287.akpm@linux-foundation.org> Content-Type: text/plain Date: Tue, 18 Nov 2008 10:17:04 +1100 Message-Id: <1226963824.7178.255.camel@pasglop> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Andrew Morton Cc: Linus Torvalds , rostedt@goodmis.org, linux-kernel@vger.kernel.org, paulus@samba.org, linuxppc-dev@ozlabs.org, mingo@elte.hu, tglx@linutronix.de, linux-mm@kvack.org List-ID: > I'd have thought so, but I'm sure we're about to hear how important an > optimisation the smaller stacks are ;) Not sure, I tend to agree that it would make sense to bump our stack to 64K on 64K pages, it's not like we are saving anything and we are probably adding overhead in alloc/dealloc. I'll see what Paul thinks here. > Yup. That being said, the younger me did assert that "this is a neater > implementation anyway". If we can implement those loops without > needing those on-stack temporary arrays then things probably are better > overall. Amen. Cheers, Ben. -- 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/ . Don't email: email@kvack.org