>> It's really not that much of a fast path. Unless you're doing something >> particularly obscure then even under heavy load you're unlikely to exceed >> a few kHz. > >I think with kvm, heavy disk stressing benchmark can get higher.
I'd still expect this to be the least of your problems. If nothing else you've at least one host signal delivery and/or thread context switch in there. Not to mention the overhead to forwarding the interrupt to the guest CPU. > > Compared to the average PIC implementation, and the overhead of the > > actual CPU interrupt, I find it hard to believe that looping over > > precisely 4 entries has any real performance hit. > > I don't think it is major, but I definitely have seen, in the past, > that extra branches and memory accesses have small but measureable effect > when taken in interrupt handler routines in drivers, and same should > apply here. > > OTOH keeping the sum around is trivial. Not entirely. You now have two different bits of information that you have to keep consistent. Unless you can show that this is performance critical code I strongly recommend keeping it as simple as possible. Paul
