Re: [PATCH 1/3] x86: enlightenment for ticket spinlocks - base implementation

[Jan Beulich]

>>> "H. Peter Anvin" <hpa@xxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/