On Tue, 18 Nov 2008, Nick Piggin wrote:
> >
> > The fact is, Intel (and to a lesser degree, AMD) has shown how hardware
> > can do good TLB's with essentially gang lookups, giving almost effective
> > page sizes of 32kB with hardly any of the downsides. Couple that with
>
> It's much harder to d
Nick Piggin writes:
> It's much harder to do this with powerpc I think because they would need
> to calculate 8 hashes and touch 8 cachelines to prefill 8 translations,
> wouldn't they?
Yeah, the hashed page table sucks. Film at 11, as they say. :)
Paul.
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 18, 2008 at 10:03:25AM +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2008-11-17 at 15:34 -0500, Steven Rostedt wrote:
> > > Note, I was using a default config that had CONFIG_IRQSTACKS off and
> > > CONFIG_PPC_64K_PAGES on.
> >
> >
On Tuesday 18 November 2008 13:08, Linus Torvalds wrote:
> On Tue, 18 Nov 2008, Paul Mackerras wrote:
> > Also, you didn't respond to my comments about the purely software
> > benefits of a larger page size.
>
> I realize that there are benefits. It's just that the downsides tend to
> swamp the ups
On Tuesday 18 November 2008 09:53, Paul Mackerras wrote:
> I'd love to be able to use a 4k base page size if I could still get
> the reduction in page faults and the expanded TLB reach that we get
> now with 64k pages. If we could allocate the page cache for large
> files with order-4 allocations
On Tue, Nov 18, 2008 at 10:03:25AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2008-11-17 at 15:34 -0500, Steven Rostedt wrote:
> > Note, I was using a default config that had CONFIG_IRQSTACKS off and
> > CONFIG_PPC_64K_PAGES on.
>
> For one, we definitely need to turn IRQSTACKS on by default .
> > 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
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Tue, 18 Nov 2008 13:36:16 +1100
> Steven Rostedt writes:
>
> > By-the-way, my box has been running stable ever since I switched to
> > CONFIG_IRQSTACKS.
>
> Great. We probably should remove the config option and just always
> use irq stacks.
That
Steven Rostedt writes:
> By-the-way, my box has been running stable ever since I switched to
> CONFIG_IRQSTACKS.
Great. We probably should remove the config option and just always
use irq stacks.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlab
On Mon, 17 Nov 2008, Steven Rostedt wrote:
>
> On Mon, 17 Nov 2008, Steven Rostedt wrote:
> >
> > Note, I was using a default config that had CONFIG_IRQSTACKS off and
> > CONFIG_PPC_64K_PAGES on.
>
> Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
> softirqs still use the s
On Tue, 18 Nov 2008, Paul Mackerras wrote:
>
> Also, you didn't respond to my comments about the purely software
> benefits of a larger page size.
I realize that there are benefits. It's just that the downsides tend to
swamp the upsides.
The fact is, Intel (and to a lesser degree, AMD) has sh
On Mon, 17 Nov 2008, Steven Rostedt wrote:
>
> And here's my i386 max stack:
>
> [EMAIL PROTECTED] ~]# cat /debug/tracing/stack_trace
> Depth Size Location(47 entries)
> -
> 0) 2216 240 blk_recount_segments+0x39/0x51
> 1) 197
On Tue, 18 Nov 2008, Paul Mackerras wrote:
> >
> > 64 bytes, still much lower than the 160 of PPC64.
>
> The ppc64 ABI has a minimum stack frame of 112 bytes, due to having an
> area for called functions to store their parameters (64 bytes) plus 6
> slots for saving stuff and for the compiler an
Steve,
> On Mon, 17 Nov 2008, Linus Torvalds wrote:
> >
> > I do wonder just _what_ it is that causes the stack frames to be so
> > horrid. For example, you have
> >
> > 18) 8896 160 .kmem_cache_alloc+0xfc/0x140
> >
> > and I'm looking at my x86-64 compile, and it has a stack fr
On Mon, 17 Nov 2008, Linus Torvalds wrote:
>
> I do wonder just _what_ it is that causes the stack frames to be so
> horrid. For example, you have
>
>18) 8896 160 .kmem_cache_alloc+0xfc/0x140
>
> and I'm looking at my x86-64 compile, and it has a stack frame of just 8
> byte
Linus Torvalds writes:
> > > 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 yo
On Mon, 2008-11-17 at 15:34 -0500, Steven Rostedt wrote:
>
> I've been hitting stack overflows on a PPC64 box, so I ran the ftrace
> stack_tracer and part of the problem with that box is that it can nest
> interrupts too deep. But what also worries me is that there's some heavy
> hitters of sta
On Tue, 18 Nov 2008, Paul Mackerras wrote:
> Steven Rostedt writes:
>
> > Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
> > softirqs still use the same stack as the process.
>
> They shouldn't. I don't see do_softirq in the trace, though. Which
> functions did you think
On Tue, 18 Nov 2008, Benjamin Herrenschmidt wrote:
>
> 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 ve
On Tue, 18 Nov 2008 10:13:16 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > 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 / 5
> 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'
> 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 pag
On Mon, 2008-11-17 at 15:59 -0500, Steven Rostedt wrote:
> On Mon, 17 Nov 2008, Steven Rostedt wrote:
> >
> > Note, I was using a default config that had CONFIG_IRQSTACKS off and
> > CONFIG_PPC_64K_PAGES on.
>
> Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
> softirqs still
On Mon, 2008-11-17 at 15:34 -0500, Steven Rostedt wrote:
> Note, I was using a default config that had CONFIG_IRQSTACKS off and
> CONFIG_PPC_64K_PAGES on.
For one, we definitely need to turn IRQSTACKS on by default ... In fact,
I'm pondering just removing the option.
Cheers,
Ben.
__
Linus Torvalds writes:
> The ppc people run databases, and they don't care about sane people
And HPC apps, and all sorts of other things...
> telling them the big pages suck. It's made worse by the fact that they
> also have horribly bad TLB fills on their broken CPU's, and years and
Taking
Steven Rostedt writes:
> Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
> softirqs still use the same stack as the process.
They shouldn't. I don't see do_softirq in the trace, though. Which
functions did you think would be run in a softirq? It looks to me
like the deepes
On Mon, 17 Nov 2008, Andrew Morton wrote:
>
> 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.
Sure, if it actually ends
On Mon, 17 Nov 2008 13:23:23 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 17 Nov 2008, Andrew Morton wrote:
> >
> > Far be it from me to apportion blame, but THIS IS ALL LINUS'S FAULT! :)
> >
> > I fixed this six years ago. See http://lkml.org/lkml/2002/6/17/68
>
>
On Mon, Nov 17, 2008 at 11:18 PM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> I do wonder just _what_ it is that causes the stack frames to be so
> horrid. For example, you have
>
> 18) 8896 160 .kmem_cache_alloc+0xfc/0x140
>
> and I'm looking at my x86-64 compile, and it has a st
On Mon, 17 Nov 2008, Andrew Morton wrote:
>
> Far be it from me to apportion blame, but THIS IS ALL LINUS'S FAULT! :)
>
> I fixed this six years ago. See http://lkml.org/lkml/2002/6/17/68
Btw, in that thread I also said:
"If we have 64kB pages, such architectures will have to have a bi
On Mon, 17 Nov 2008, Steven Rostedt wrote:
>
> Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
> softirqs still use the same stack as the process.
Yes.
> This is still 12K. Kind of big even for a 16K stack.
And while that 1kB+ stack slot for block_read_full_page still sta
On Mon, 17 Nov 2008 15:34:13 -0500 (EST)
Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> I've been hitting stack overflows on a PPC64 box, so I ran the ftrace
> stack_tracer and part of the problem with that box is that it can nest
> interrupts too deep. But what also worries me is that there's s
On Mon, 17 Nov 2008, Steven Rostedt wrote:
>
> 45) 49921280 .block_read_full_page+0x23c/0x430
> 46) 37121280 .do_mpage_readpage+0x43c/0x740
Ouch.
> Notice at line 45 and 46 the stack usage of block_read_full_page and
> do_mpage_readpage. They each use 1280 bytes of stack!
On Mon, 17 Nov 2008, Steven Rostedt wrote:
>
> Note, I was using a default config that had CONFIG_IRQSTACKS off and
> CONFIG_PPC_64K_PAGES on.
Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
softirqs still use the same stack as the process.
[EMAIL PROTECTED] ~> cat /debug/t
I've been hitting stack overflows on a PPC64 box, so I ran the ftrace
stack_tracer and part of the problem with that box is that it can nest
interrupts too deep. But what also worries me is that there's some heavy
hitters of stacks in generic code. Namely the fs directory has some.
Here's the
35 matches
Mail list logo
