"Brown, Len" <[email protected]> writes:
>>In the case of ACPI. I think the mptable case has all of information
>>in mp_irqs at that point.
>
> Agreed, I just sent a note on this, but apparently it "crossed
> in the mail" with yours. The key point about MPS is that MPS
> should not describe pins that can never be connected -- so that isn't
> quite as bad as handing out a vector for every RTE, which is what the
> code appears to do on first read...
Makes sense.
>>I agree with the fact, we do allocate the vectors on-demand.
>>Since the allocation is not allowed to fail, and because
>>it seems to be an accident of the implementation rather
>>than a deliberate implementation detail I still think it
>>needs to be fixed so the code is less brittle.
>
> Yeah, it isn't clear that this has any advantage over assigning
> the vector at request_irq() time where one would expect to see it.
> Though some might consider "currently working" an advantage:-)
Right. This will have to wait until I can start sending patches.
>>But if we are not afraid of breaking machines with more
>>that 243 interrupt sources (which currently force ioapic/pin
>>combinations to share irqs today) it does mean we can move
>>the removal of the irq to gsi mapping up, in the patch series. We
>>first need to raise the limit on the number of IRQs on x86.
>
> No, I don't think we have the license to intentionally break big
> machines
> that are currently working.
No but it may be ok. At an intermediate step in a series of patches.
Although ideally even that would never happen.
> In the long run, these two big-machine
> hacks should go away:
>
> mp_register_gsi()
> /*
> * For PCI devices, assign IRQs in order, avoiding gaps
> * due to unused I/O APIC pins.
> */
> ...
>
> io_apic_set_pci_routing() (x86_64 only upstream, i386 too on SuSE)
> irq = gsi_irq_sharing(irq)
>
>
> I think what we can do in the short term is to make these workarounds
> not have any effect on the systems which don't need them. This means
> searching like gsi_irq_sharing() does, instead of always compressing
> like mp_register_gsi() does. It also means not printing dmesg
> about vector sharing when no sharing is actually happening.
I'm a long run kind of guy :)
As soon as I clean up my proof of concept code and send it
out I will have both of those killed.
> Based on past history of the un-intended impact of interrupt changes,
> (eg. what started this thread)
> I would suggest that only the simplest things go into 2.6.18
> and that the larger changes stay in -mm for all of 2.6.18
> and targtet 2.6.19.
That makes sense. I'm in no hurry :) Mostly my intention was
that this is not 2.6.17 material and whatever short term hacks
are needed to make 2.6.17 work need to go in now.
Eric
-
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]
