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
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
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
> +
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
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
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
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
> 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
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
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?
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?
--
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
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
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
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
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
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
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
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
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
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
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
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.
Signed-off-by:
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.
Signed-off-by:
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
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
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
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
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
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
30 matches
Mail list logo
