From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: Large stack usage in fs code (especially for PPC64)
Date: Tue, 18 Nov 2008 18:25:20 +1100 [thread overview]
Message-ID: <1226993120.7178.287.camel@pasglop> (raw)
In-Reply-To: <alpine.LFD.2.00.0811171522030.18283@nehalem.linux-foundation.org>
> > 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.
next prev parent reply other threads:[~2008-11-18 7:25 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-17 20:34 Large stack usage in fs code (especially for PPC64) Steven Rostedt
2008-11-17 20:59 ` Steven Rostedt
2008-11-17 21:18 ` Linus Torvalds
2008-11-17 21:25 ` Pekka Enberg
2008-11-18 0:54 ` Steven Rostedt
2008-11-18 1:05 ` Paul Mackerras
2008-11-18 1:41 ` Steven Rostedt
2008-11-18 2:01 ` Steven Rostedt
2008-11-17 22:16 ` Paul Mackerras
2008-11-17 23:30 ` Steven Rostedt
2008-11-17 23:04 ` Benjamin Herrenschmidt
2008-11-18 2:29 ` Steven Rostedt
2008-11-18 2:36 ` Paul Mackerras
2008-11-18 5:40 ` David Miller
2008-11-17 21:08 ` Andrew Morton
2008-11-17 21:23 ` Linus Torvalds
2008-11-17 21:31 ` Andrew Morton
2008-11-17 21:42 ` Linus Torvalds
2008-11-17 23:17 ` Benjamin Herrenschmidt
2008-11-17 21:09 ` Linus Torvalds
2008-11-17 22:53 ` Paul Mackerras
2008-11-18 10:07 ` Nick Piggin
2008-11-17 23:13 ` Benjamin Herrenschmidt
2008-11-17 23:22 ` Josh Boyer
2008-11-17 23:28 ` Linus Torvalds
2008-11-18 0:11 ` Paul Mackerras
2008-11-18 2:08 ` Linus Torvalds
2008-11-18 10:24 ` Nick Piggin
2008-11-18 11:44 ` Paul Mackerras
2008-11-18 16:02 ` Linus Torvalds
2008-11-18 7:25 ` Benjamin Herrenschmidt [this message]
2008-11-17 23:03 ` Benjamin Herrenschmidt
2008-11-18 9:53 ` Christoph Hellwig
2008-11-18 10:37 ` Ingo Molnar
2008-11-17 23:30 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1226993120.7178.287.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).