Re: [PATCH v1] KVM: s390: use switch vs jump table in interrupt.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 02/08/2018 09:14 AM, Cornelia Huck wrote:
> On Wed, 7 Feb 2018 19:28:04 +0100
> Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:
> 
>> I see a minimal regression for uperf 1byte ping pong between two guests (~3%)
>> Probably because the old code first handled IO interrupts and then did the remaing
>> stuff.  Not sure if its worth to keep the old io_ioirq hack.
> 
> Hm, that confuses me a bit. We search the pending bit map, which should
> give us the irq with the highest priority, and the switch/case still
> starts out with I/O interrupts.

gcc does not obey the order of the case statements. It uses several heuristics depending
on the size and others. So gcc might fall back to jump tables for large switches, or
it uses bisecting or it might even split the search into a jump table and several
relative branches if there are strange distributions. Quite often the default 
case is evaulated first.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux