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 A498BDDE0F for ; Tue, 18 Nov 2008 18:25:59 +1100 (EST) Subject: Re: Large stack usage in fs code (especially for PPC64) From: Benjamin Herrenschmidt To: Linus Torvalds In-Reply-To: References: <1226963596.7178.254.camel@pasglop> Content-Type: text/plain Date: Tue, 18 Nov 2008 18:25:20 +1100 Message-Id: <1226993120.7178.287.camel@pasglop> Mime-Version: 1.0 Cc: Thomas Gleixner , LKML , Steven Rostedt , linuxppc-dev@ozlabs.org, Paul Mackerras , Andrew Morton , Ingo Molnar List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > > It makes some sort of sense I suppose on very static embedded workloads > > with no swap nor demand paging. > > It makes perfect sense for anything that doesn't use any MMU. To a certain extent. There's two different aspects to having an MMU and in embedded space it's useful to have one and not the other, ie, protection & address space isolation vs. paging. Thus, it does make sense for those embedded devices with few files (mostly a statically linked busybox, a few /dev entries and some app stuff) to use large page sizes. Of course, as soon as they try to populate their ramfs with lots of small files they lose... but mostly, the idea is that the entire working set fits in the TLB and thus the cost of TLB miss becomes irrelevant. Now, regarding the shortcomings of the powerpc server MMU, well, we know them, we know your opinion and mostly share it, and until we can get the HW to change we are stuck with it. Cheers, Ben.