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 10:13:16 +1100 [thread overview]
Message-ID: <1226963596.7178.254.camel@pasglop> (raw)
In-Reply-To: <alpine.LFD.2.00.0811171300410.18283@nehalem.linux-foundation.org>
> Well, it's not unacceptable on good CPU's with 4kB blocks (just an 8-entry
> array), but as you say:
>
> > On PPC64 I'm told that the page size is 64K, which makes the above equal
> > to: 64K / 512 = 128 multiply that by 8 byte words, we have 1024 bytes.
>
> Yeah. Not good. I think 64kB pages are insane. In fact, I think 32kB
> pages are insane, and 16kB pages are borderline. I've told people so.
>
> The ppc people run databases, and they don't care about sane people
> telling them the big pages suck.
Hehe :-)
Guess who is pushing for larger page sizes nowadays ? Embedded
people :-) In fact, we have patches submited on the list to offer the
option for ... 256K pages on some 44x embedded CPUs :-)
It makes some sort of sense I suppose on very static embedded workloads
with no swap nor demand paging.
> It's made worse by the fact that they
> also have horribly bad TLB fills on their broken CPU's, and years and
> years of telling people that the MMU on ppc's are sh*t has only been
> reacted to with "talk to the hand, we know better".
Who are you talking about here precisely ? I don't think either Paul or
I every said something nearly around those lines ... Oh well.
But yeah, our existing server CPUs have pretty poor TLB refills and yes,
64K pages help. And yes, we would like things to be different, but they
aren't.
But there is also pressure to get larger page sizes from small embedded
field, where CPUs have even poorer TLB refill (software loaded
basically) :-)
> Quite frankly, 64kB pages are INSANE. But yes, in this case they actually
> cause bugs. With a sane page-size, that *arr[MAX_BUF_PER_PAGE] thing uses
> 64 bytes, not 1kB.
Come on, the code is crap to allocate that on the stack anyway :-)
> Of course, that would likely mean that FAT etc wouldn't work on ppc64, so
> I don't think that's a valid model either. But if the 64kB page size is
> just a "database server crazy-people config option", then maybe it's
> acceptable.
Well, as I said, embedded folks are wanting that too ...
Cheers,
Ben.
next prev parent reply other threads:[~2008-11-17 23:13 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 [this message]
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
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=1226963596.7178.254.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).