[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <491CB500.8090203@sgi.com>
Date: Thu, 13 Nov 2008 15:15:12 -0800
From: Mike Travis <travis@....com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Yinghai Lu <yinghai@...nel.org>, mingo@...e.hu, tglx@...utronix.de,
hpa@...or.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sparse_irq aka dyn_irq v13
Andrew Morton wrote:
> On Thu, 13 Nov 2008 14:41:36 -0800
> Yinghai Lu <yinghai@...nel.org> wrote:
>
>> Andrew Morton wrote:
>>
>>>> ...
>>>>
>>>>>> +static unsigned int kstat_irqs_legacy[NR_IRQS_LEGACY][NR_CPUS];
>>>>> Do these need to be 32-bit? Maybe they'll fit in 16-bit, dunno.
>>>>>
>>>> struct irq_desc {
>>>> unsigned int irq;
>>>> #ifdef CONFIG_SPARSE_IRQ
>>>> struct list_head list;
>>>> struct list_head hash_entry;
>>>> struct timer_rand_state *timer_rand_state;
>>>> unsigned int *kstat_irqs;
>>> That doesn't address my question.
>>>
>>> The above array can be very large. Can we halve its size by using
>>> 16-bit quantities? Will this code ever encounter IRQ numbers larger
>>> than 65536?
>>>
>> NR_CPUS=4096, NR_IRQS_LEGACY=16, and that array will be 256k bytes
>>
>> later could change that alloc_bootmem, so NR_CPUS will be replaced to nr_cpu_ids
>
> Do the entries in that array need to be 32-bit?
That's a good question. If there are 4k or 16k cpus, would the number of
irq's being "kstat'd" need to be > 64k? (I'm not exactly sure why there
are NR_CPUS * NR_IRQS_LEGACY kstat entries per IRQ?)
--
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