On Tue, Mar 10, 2015 at 2:21 PM, Ingo Molnar <[email protected]> wrote: >> Since this patch does add two extra MOVs, >> I did benchmark these patches. They add exactly one cycle >> to system call code path on my Sandy Bridge CPU. > > Hm, but that's the wrong direction, we should try to make it faster, > and to clean it up
As you know, goals of "faster" and "cleaner" are often mutually exclusive. C'est la vie :( entry.S seem to lean towards "faster" to the extent where it became a tangled maze of obscure optimizations. Such as the mysterious, and not at all obvious existence of 8 byte "safety padding" at the top of the 32-bit kernel stack. Before Andy stumbled into it, it was not at all obvious that it is even there. I had to write a test patch to verify it. There is a long-standing latent bug in the code where this padding is not accounted for. > - but making it slower without really good reasons isn't good. The thinking here is that cleaning up entry.S is a good reason. We won't do anything which would slow it down by, say, 5%, but one cycle may be considered acceptable loss. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
