Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, Apr 30, 2007 at 10:43:10AM -0700, William Lee Irwin III wrote: >> + Allocates the stack physically discontiguously and from high >> + memory. Furthermore an unmapped guard page follows the stack. >> + This is not for end-users. It's intended to trigger fatal >> + system errors under various forms of stack abuse. On Fri, May 04, 2007 at 01:35:30AM -0400, Joseph Fannin wrote: > Why is this not for end-users? Will it not trigger anything > useful unless set up properly, or is a big performace hit -- and how, > or what? > All the kernel debug options are underdocumented this way -- I'd > like to have as many of them on as I can without absolutely killing > performance, (or rather, *you* would) -- but I can never tell without > grovelling all over for the info, which... well, I haven't done it > yet, anyway. There aren't many effective sideband methods to document things. If I knew of an "expanded help" thing people could look at in Kconfig, I'd write storybook documentation and put it there as I'm wont to do. On Fri, May 04, 2007 at 01:35:30AM -0400, Joseph Fannin wrote: > "End-user" is just insufficently defined for anyone compiling > their own kernel. Could you add a bit more text here describing what > the effect of physically discontiguous high-memory stacks is? An > additional frobnitz dereference on every badda-bing badda-bang, likely > to double the time it takes to dance the hokey pokey? >*shrug* Some of those debug options probably don't get set very > often on kernels that are run for more than to see if it boots. It's short for "whoever doesn't understand the terse jargon" as I'm using it. The assumption here is that it's essentially for kernel hackers who know all about kernel internals up-front anyway. The option really is not to be trifled with. Maybe I could work with the kerneldoc developers to arrange for outlets for more verbose documentation for options (actually I'd like similar for API functions as well; I'd like to write IRIX-style roman fleuve manpages for things). There is a slight danger, though, that the documentation may get out of synch. For now, I just have nowhere appropriate to put it. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, Apr 30, 2007 at 10:43:10AM -0700, William Lee Irwin III wrote: > + Allocates the stack physically discontiguously and from high > + memory. Furthermore an unmapped guard page follows the stack. > + This is not for end-users. It's intended to trigger fatal > + system errors under various forms of stack abuse. Why is this not for end-users? Will it not trigger anything useful unless set up properly, or is a big performace hit -- and how, or what? All the kernel debug options are underdocumented this way -- I'd like to have as many of them on as I can without absolutely killing performance, (or rather, *you* would) -- but I can never tell without grovelling all over for the info, which... well, I haven't done it yet, anyway. "End-user" is just insufficently defined for anyone compiling their own kernel. Could you add a bit more text here describing what the effect of physically discontiguous high-memory stacks is? An additional frobnitz dereference on every badda-bing badda-bang, likely to double the time it takes to dance the hokey pokey? *shrug* Some of those debug options probably don't get set very often on kernels that are run for more than to see if it boots. -- Joseph Fannin [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Tue, May 01, 2007 at 05:36:06PM -0500, Matt Mackall wrote: >>> Can we register them lazily at request_irq time? On Tue, May 01, 2007 at 03:51:25PM -0700, Bill Irwin wrote: >> These IRQ stacks are per-cpu, not per-IRQ. It may make sense to >> implement per-IRQ stacks, in which case dynamic allocation at the time >> of request_irq() will make sense. >> Would you like me to implement per-IRQ IRQ stacks? On Tue, May 01, 2007 at 06:15:48PM -0500, Matt Mackall wrote: > It's probably the "right" thing to do, but it does have higher > overhead for most systems. > But it also gives a very obvious migration path to -rt's irq threads. Well, I don't really know how much of -rt or which pieces of it are really going in. Otherwise it favors large-scale i386, which people largely want to ignore/break/etc. I'll err on the side of caution and not change it. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
At some point in the past, I wrote: >> These IRQ stacks are per-cpu, not per-IRQ. It may make sense to >> implement per-IRQ stacks, in which case dynamic allocation at the time >> of request_irq() will make sense. On Wed, May 02, 2007 at 12:07:45AM +0100, Alan Cox wrote: > This depends if active IRQ count exceeds active CPU count worst cases. > For the big boxes it might well do but for small ones we seem to be best > with per CPU. I'll leave IRQ stacks per-CPU, then. The prevailing opinion on large i386 does not favor doing much of anything to accommodate it. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Tue, May 01, 2007 at 03:51:25PM -0700, Bill Irwin wrote: > On Mon, Apr 30, 2007 at 08:15:11PM +0100, Christoph Hellwig wrote: > >> So if you want to invest some time into getting this into mergeable > >> shape I'd suggest you redo the patch series in the following way: > >> patch 1: dynamic allocated irq stacks > > On Tue, May 01, 2007 at 05:36:06PM -0500, Matt Mackall wrote: > > Can we register them lazily at request_irq time? > > These IRQ stacks are per-cpu, not per-IRQ. It may make sense to > implement per-IRQ stacks, in which case dynamic allocation at the time > of request_irq() will make sense. > > Would you like me to implement per-IRQ IRQ stacks? It's probably the "right" thing to do, but it does have higher overhead for most systems. But it also gives a very obvious migration path to -rt's irq threads. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
> These IRQ stacks are per-cpu, not per-IRQ. It may make sense to > implement per-IRQ stacks, in which case dynamic allocation at the time > of request_irq() will make sense. This depends if active IRQ count exceeds active CPU count worst cases. For the big boxes it might well do but for small ones we seem to be best with per CPU. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, Apr 30, 2007 at 08:15:11PM +0100, Christoph Hellwig wrote: >> So if you want to invest some time into getting this into mergeable >> shape I'd suggest you redo the patch series in the following way: >> patch 1: dynamic allocated irq stacks On Tue, May 01, 2007 at 05:36:06PM -0500, Matt Mackall wrote: > Can we register them lazily at request_irq time? These IRQ stacks are per-cpu, not per-IRQ. It may make sense to implement per-IRQ stacks, in which case dynamic allocation at the time of request_irq() will make sense. Would you like me to implement per-IRQ IRQ stacks? -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, Apr 30, 2007 at 08:15:11PM +0100, Christoph Hellwig wrote: > So if you want to invest some time into getting this into mergeable > shape I'd suggest you redo the patch series in the following way: > > patch 1: dynamic allocated irq stacks Can we register them lazily at request_irq time? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, Apr 30, 2007 at 08:15:11PM +0100, Christoph Hellwig wrote: > So if you want to invest some time into getting this into mergeable > shape I'd suggest you redo the patch series in the following way: > patch 1: dynamic allocated irq stacks > patch 2: make irqstacks unconditional, but allow selecting 4/8k stacks > patch 3: introduce a DEBUG_STACK option that enables vmalloc'ed stacks > and adds the __pa check. I've not heard anything back on this from freitag, so I've redone the patch series precisely as you've outlined above. I'm taking the updated patch series through a battery of testboots before posting for merging purposes. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, Apr 30, 2007 at 08:15:11PM +0100, Christoph Hellwig wrote: > So if you want to invest some time into getting this into mergeable > shape I'd suggest you redo the patch series in the following way: > patch 1: dynamic allocated irq stacks > patch 2: make irqstacks unconditional, but allow selecting 4/8k stacks > patch 3: introduce a DEBUG_STACK option that enables vmalloc'ed stacks > and adds the __pa check. This was actually done for work purposes, hence the change of email addresses. I can redo it in such a manner, provided it's not duplicating mergework Andi Kleen intends to do or otherwise includes pieces (like the __pa() check) he'd prefer to drop. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
So if you want to invest some time into getting this into mergeable shape I'd suggest you redo the patch series in the following way: patch 1: dynamic allocated irq stacks patch 2: make irqstacks unconditional, but allow selecting 4/8k stacks patch 3: introduce a DEBUG_STACK option that enables vmalloc'ed stacks and adds the __pa check. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, Apr 30, 2007 at 10:43:10AM -0700, William Lee Irwin III wrote: >> Add a config option to vmalloc() task stacks so that stack overflows are >> detected without fail, and with a fatal failure mode at that. On Mon, Apr 30, 2007 at 07:11:04PM +0100, Christoph Hellwig wrote: > Whee, this sounds like a really helpful although costly debugging option. If desired, I can redo it standalone. It should be clear from the remainder of the series of debug patches that it's readily extensible to IRQ stacks for similar purposes, as IRQ stacks are similarly vmalloc()'d by later patches in the series. The patch to make __pa() BUG() on vmallocspace addresses may also be worthy of consideration in conjunction with vmalloc()'ing the stack. That particular patch was suggested by freitag. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Apr 30 2007 19:11, Christoph Hellwig wrote: >On Mon, Apr 30, 2007 at 10:43:10AM -0700, William Lee Irwin III wrote: >> On Mon, Apr 30, 2007 at 10:38:19AM -0700, William Lee Irwin III wrote: >> > Here's what I did for i386 for someone concerned about blowing the stack. >> >> Add a config option to vmalloc() task stacks so that stack overflows are >> detected without fail, and with a fatal failure mode at that. > >Whee, this sounds like a really helpful although costly debugging option. Options are there to be disabled, making the cost ideally zero for people who do not want a specific feature. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] add config option to vmalloc stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, Apr 30, 2007 at 10:43:10AM -0700, William Lee Irwin III wrote: > On Mon, Apr 30, 2007 at 10:38:19AM -0700, William Lee Irwin III wrote: > > Here's what I did for i386 for someone concerned about blowing the stack. > > Add a config option to vmalloc() task stacks so that stack overflows are > detected without fail, and with a fatal failure mode at that. Whee, this sounds like a really helpful although costly debugging option. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
