> On Tuesday 02 May 2006 09:41, Brown, Len wrote:
>
> > You are right. This code is wrong.
> > It makes absolutely no sense to reserve vectors in advance
> for every
> > RTE in the IOAPIC when we don't even know if they are going to be
> > used.
> >
> > This is clearly a holdover from the early IOAPIC/MPS days
> when we were
> > talking about 4 to 8 non-legacy RTEs.
>
> Yes I agree. A lot of the IO-APIC code could probably need
> some renovation.
>
> > This is where the big system vector shortage problem should be
> > addressed.
>
> If we go to per CPU IDTs it will be much less pressing, but
> still a good idea.
>
I've been trying to put together something on per-CPU IDTs also, and got
entangled in all those issues that you just discussed... Dynamically
assigning vectors to IRQs sounds like great improvement of the mechanism
(why would they need to be static really), and vectors are right
entities to manipulate with - while keeping IRQs stable and representing
the interrupts sources clearly to the user.
Len, I suppose it would make sense to accept the Kimball's timer fix for
now, before the whole re-implementation happens?
--Natalie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
