On Thu, 8 Feb 2018 10:53:00 +0100 Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > 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. But should we really try to optimize something that may change with a different compiler anyway? The important thing is the priority in the bitmap. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
