[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070430200301.GE26598@holomorphy.com>
Date: Mon, 30 Apr 2007 13:03:01 -0700
From: Bill Irwin <bill.irwin@...cle.com>
To: Zwane Mwaikambo <zwane@...radead.org>
Cc: Andi Kleen <andi@...stfloor.org>,
Christoph Hellwig <hch@...radead.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
David Chinner <dgc@....com>, Zan Lynx <zlynx@....org>,
Adrian Bunk <bunk@...sta.de>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [5/6] dynamically allocate IRQ stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, 30 Apr 2007, William Lee Irwin III wrote:
>> -static char softirq_stack[NR_CPUS * THREAD_SIZE]
>> - __attribute__((__aligned__(THREAD_SIZE)));
>> +static DEFINE_PER_CPU(char *, softirq_stack);
>> +static DEFINE_PER_CPU(char *, hardirq_stack);
>>
>> -static char hardirq_stack[NR_CPUS * THREAD_SIZE]
>> - __attribute__((__aligned__(THREAD_SIZE)));
>> +#ifdef CONFIG_VMALLOC_STACK
>> +static void * __init __alloc_irqstack(int cpu)
On Mon, Apr 30, 2007 at 12:49:04PM -0700, Zwane Mwaikambo wrote:
> How about just using DEFINE_PER_CPU and allowing the percpu code
> dynamically allocate.
The indirection was needed to vmalloc()/vmap() the IRQ stacks. It
should probably be decided explicitly whether vmalloc() of the IRQ
stacks is considered desirable for any mainline merge of these things.
This code is by no means sacred to me, so I have no particular
preference with respect to the suggested tradeoffs or reworks. Whatever
people want out of all this for mainline (even if nothing) is fine by me.
-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists