Hi folks, One piece of code that I've always considered ugly and potentially performing badly was the instruction emulator. For booke, it goes as far as 3 cascaded switch statements throughout different C files. It's so ungeneric, that it robs us of any possibility to selectively save/restore non-volatile registers and it makes it really hard to implement target CPUs that are different from the host CPU. So I sat down and figured "let's try to make this whole thing a bit nicer - throw everything into a table and give every function a flag we can interpret". That gave me a few nice function call tables with associated flags, that even allow me to selectively save/restore non-volatile registers! Awesome, eh? Well, no. Turns out, the whole thing - even with the NV GPR optimization - is 1.4% _slower_ than the cascaded switch statements. Admittedly, I only benchmarked on book3s, but the results were quite consistent. I would've expected more of a speedup rather than a slowdown. So here are the pros and cons of the table based emulation: Pro: * cleaner, can put operations in more generic places throughout the code * allows for more host cpu != guest cpu combinations. Cons: * slower * more code size (individual functions bloat the code) * more runtime size overhead (kmalloc'ed jump tables) If you're interested in checking out the code, here it goes: https://github.com/agraf/linux-2.6/commits/emul-rework git://github.com/agraf/linux-2.6.git emul-rework So for the time being, I'll just pick the raisins of that work and leave the actual rework be. We gain too little and lose too much for such a massive code change. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
