2007-05-01 17:05:34

by Heiko Carstens

[permalink] [raw]
Subject: Re: [1/3] dynamically allocate IRQ stacks

> +static void * __init __alloc_irqstack(int cpu)
> +{
> + if (!cpu)
> + return __alloc_bootmem(THREAD_SIZE, THREAD_SIZE,
> + __pa(MAX_DMA_ADDRESS));
> +
> + return (void *)__get_free_pages(GFP_KERNEL,
> + ilog2(THREAD_SIZE/PAGE_SIZE));
> +}

I think you should test for slab_is_available() instead of checking
if the cpu number is 0.


2007-05-01 17:30:50

by Bill Irwin

[permalink] [raw]
Subject: Re: [1/3] dynamically allocate IRQ stacks

At some point in the past, I wrote:
>> +static void * __init __alloc_irqstack(int cpu)
>> +{
>> + if (!cpu)
>> + return __alloc_bootmem(THREAD_SIZE, THREAD_SIZE,
>> + __pa(MAX_DMA_ADDRESS));
>> +
>> + return (void *)__get_free_pages(GFP_KERNEL,
>> + ilog2(THREAD_SIZE/PAGE_SIZE));
>> +}

On Tue, May 01, 2007 at 07:04:26PM +0200, Heiko Carstens wrote:
> I think you should test for slab_is_available() instead of checking
> if the cpu number is 0.

Plausible, though it would appear somewhat incongruous given that no
direct calls to slab functions are made. The timing should still come
out right, given that the vmallocspace variant needs to run late enough
for mm/vmalloc.c's internal slab allocations to work.

The patches end up looking like the following MIME attachments with
your suggested change.


-- wli


Attachments:
(No filename) (825.00 B)
dynamic-irq-stacks.patch (4.05 kB)
dynamic-irq-stacks.patch
unconditional-i386-irq-stacks.patch (2.43 kB)
unconditional-i386-irq-stacks.patch
debug-stack.patch (9.08 kB)
debug-stack.patch
Download all attachments