On 2012-07-14 04:25, Thomas Gleixner wrote: > On Fri, 13 Jul 2012, Thomas Gleixner wrote: >> On Fri, 13 Jul 2012, Linus Torvalds wrote: >>> On Fri, Jul 13, 2012 at 8:45 AM, Linus Torvalds >>> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >>> At the same time, I do wonder if maybe MSI + IRQF_ONESHOT couldn't be >>> improved. The fact that the KVM people think that the extra overhead >>> of IRQF_ONESHOT is a bad thing for MSI interrupts makes me wonder if >>> maybe this wouldn't be an area the irq layer couldn't be improved on. >>> Maybe the MSI+IRQF_ONESHOT case could be improved. Because MSI is kind >>> of fundamentally one-shot, since it's a message-based irq scheme. So >>> maybe the extra overhead is unnecessary in general, not just in this >>> particular KVM case. Hmm? >>> >>> Thomas, see the commentary of a76beb14123a ("KVM: Fix device >>> assignment threaded irq handler"). >> >> Groan. >> >> We already discussed to let the irq chip (in this case MSI) tell the >> core that it does not need the extra oneshot handling. That way the >> code which requests an threaded irq with the NULL primary handler >> works on both MSI and normal interrupts. > > That's the kind of stuff which makes me go berserk, and just for the > record: the most complaints I get for going berserk are coming from > the virt folks. > > I really can't understand why the virt folks think they are > special and do not have to talk to core maintainers. > > Back then when I was doing the big irq cleanup, virt crap stood out by > far with the most idiotic^Wcreative "workarounds". Of course nobody > complained about me being moronic enough to come up with generic > solutions for their problems. > > Though especially that commit including its changelog proves once > again the ignorance and desinterest of the virt crowd in solving > problems which are not only relevant to themself. > > I whish you'd just refused to pull that nonsense and instead made them > talk to those folks who had a proper solution in mind already. > > In fact we could have solved that proper weeks ago, if only people > would have raised the issue. June 1: http://thread.gmane.org/gmane.linux.kernel/1306742 The proper solution for us will be conditional direct IRQ delivery anyway [1], but those patches were not considered ready for 3.5. This patch here is a workaround to unbreak devices assignment in 3.5 after the IRQ layer changes without regressing noticeable /wrt overhead. Jan [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/92249
Attachment:
signature.asc
Description: OpenPGP digital signature