lkml.org 
[lkml]   [2007]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] i386 IOAPIC: de-fang IRQ compression
Date
"Natalie Protasevich" <protasnb@gmail.com> writes:

> On Nov 27, 2007 10:21 PM, Len Brown <lenb@kernel.org> wrote:
>> commit c434b7a6aedfe428ad17cd61b21b125a7b7a29ce
>> (x86: avoid wasting IRQs for PCI devices)
>> created a concept of "IRQ compression" on i386
>> to conserve IRQ numbers on systems with many
>> sparsely populated IO APICs.
>>
>> The same scheme was also added to x86_64,
>> but later removed when x86_64 recieved an IRQ over-haul
>> that made it unnecessary -- including per-CPU
>> IRQ vectors that greatly increased the IRQ capacity
>> on the machine.
>>
>> i386 has not received the analogous over-haul,
>> and thus a previous attempt to delete IRQ compression
>> from i386 was rejected on the theory that there may
>> exist machines that actually need it. The fact is
>> that the author of IRQ compression patch was unable
>> to confirm the actual existence of such a system.
>
> Those systems did exist (and still exist actually). They used over 200
> irqs sometimes and with "normal" IRQ allocation they were failing even
> before reaching half of their I/O configuration. So simple removal
> wouldn't work for those, dynamic allocation sure would. They "scrolled
> off the topic" though because new generations of such machines are not
> 32 bit anymore. So the author didn't actually object :) it was the
> other users of large 32 bit platforms that did.

Natalie. Did they just have over 200 irqs/gsis or did they actually
use over 200 irqs?

In particular is a large NR_IRQS plus dynamic vector allocation
sufficient for all cases you know about?

Eric


\
 
 \ /
  Last update: 2007-12-06 00:29    [W:0.167 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site