On 06/20/2012 02:41 PM, Suresh Siddha wrote: >> >> OK, stupid question: WHY? >> >> In general, in Linux the random prioritization is actually a negative. > > Thinking loud in the context of your e-mail. With the relatively recent > changes like the commit mentioned below, window of higher priority class > preempting the lower priority class is minimized to the point at which > the cpu decides which interrupt to be serviced next. And in this case, > it doesn't matter if the two vectors are in two different priority > classes or the same class. Higher the vector number higher the priority > for the cpu to service next. > > commit e58aa3d2d0cc01ad8d6f7f640a0670433f794922 > Author: Ingo Molnar <mingo@xxxxxxx> > Date: Fri Mar 26 00:06:51 2010 +0000 > > genirq: Run irq handlers with interrupts disabled > > >> The only reason for the spreading by 8 is because of bugs/misfeatures in >> old APIC implementations which made them handle more than two interrupts >> per priority level rather inefficiently. > > Peter, Is it just inefficiency or a functional bug in those old apic's? > Just wondering if it is just inefficiency and given the above linux > behavior does the inefficiency matter? > > Anyways, these are old platforms that we probably don't want to mess > with. Perhaps we should go back to '8' and add a comment with all this > info, that the real intention is not to spread them across different > priority class but to avoid running into some old apic bugs. > I think it's just an inefficiency, in the sense that the interrupt will be held at the IOAPIC until the LAPIC frees up a slot, but I could be wrong. xAPIC implementations can queue an interrupt per vector, and so are unaffected; arguably we might not even want to do the "spread by 8" at all on those implementations. Overall, I think there is no real upside or downside, but the poster seemed to assume that there would be an automatic upside, and I don't think there is. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|