Messages in this thread | | | Date | Tue, 02 Feb 2010 09:04:33 +0000 | From | "Jan Beulich" <> | Subject | Re: [PATCH 1/3] x86: enlightenment for ticket spinlocks - base implementation |
| |
>>> "H. Peter Anvin" <hpa@zytor.com> 01.02.10 23:54 >>> >I'm really not very happy with the way the asm statement is chopped to >bits here. It is quite frankly much cleaner to have a little bit of >code replication and have two separate clean asm/alternative_io >implementations.
Yeah, that's a tradeoff I wasn't sure about either. I can easily change this, but to me it seemed more desirable to have less duplication.
>A thought, however: > >the sequence "rep;nop; movb %1,%b0" should be enough bytes to be able to >overwrite it with a call instruction. I am not sure if the existing
Hmm, yes, including the branch there would be 6 bytes guaranteed.
>macros allow for overwriting part of an asm statement, but it might be >an interesting thing to do. That should eliminate the funnies you have
They don't currently, but adding an offset shouldn't be that difficult. The goal certainly was to avoid touching the alternative instructions infrastructure more than absolutely necessary.
>with rip-relative addressing (which may very well be the preferred >addressing modes.) It should also give you the return address without >having to play games with pushing it onto the stack as anything other >than a return address...
Yes, for the locking path. The unlocking path could also be done with a "proper" call (even without adjustments to the alternative instructions data structures), but would introduce more branches in the inline stub. It's not clear to me whether that's better.
So if you want me to give that a try, I certainly will, provided the alternative instructions adjustments needed won't increase the resistance to the patch.
Jan
| |