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

Christian Borntraeger
2018-02-08T09:53:00Z

On 02/08/2018 09:14 AM, Cornelia Huck wrote:
> On Wed, 7 Feb 2018 19:28:04 +0100
> Christian Borntraeger <borntraeger@de.ibm.com> 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.