On Thu, Feb 14, 2013 at 2:50 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > At least on x86, how about saving *all* volatile registers in > the slow out of line code path (to stack)? Sure. The reason I suggested perhaps not saving %rax/%rdx is simply that if it's a function that returns a value, %rax obviously cannot be saved anyway. And then I was confused about the calling convention, and said %rx because it's the second argument register, but that's only true on x86-32 (with our regparm calling convention). On x86-64, it's %rdi/%rsi that have arguments. Anyway, argument registers *can* be useful to save, but are often computed, so it can go either way. > It blows up the slow path somewhat, but it would allow us to > keep the fast-path register impact even smaller - as the slow > path would only have memory content side effects. > > Am I missing something? The best option would be to just let the user say which registers it wants saved for any particular function. We'd probably want some default set so that people who call "unlikely()" functions can just pick that one, but for architecture-specific helper functions for locking etc, we would probably want to optimize it for usage (ie "is the argument likely to be useful to the caller after the call"). Sometimes saving everything is the right thing to do, sometimes it might just be extra work. And even *if* the callee saves everything, the caller still ends up being constrained by the calling convention (ie fixed registers for arguments), so it could mess up code generation in the caller for that reason. But at least it would be much less painful. Btw, it may end up that almost nobody cares. Modern CPU's are really good at handling the straightforward "save/restore to stack" instructions. One of the reasons I care is not performance per se, butu the fact that I still look at asm code every time I do any performance profiling, and it's absolutely horrible to see the code when you see "ugh, that's pointless". I'm sensitive to the spinlocks in particular, because we've gone back and forth on inlining them before, so I've seen this. But right now I don't think we inline the lock under normal configs *anyway*, so I guess it doesn't much matter. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html