On 02/08/2018 11:00 AM, Cornelia Huck wrote: > 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. An if before the switch would always prefer that condition. But I agree,we should probably not go down this path of micro optimization. -- 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
