Messages in this thread | | | Date | Wed, 20 Jan 2010 12:14:22 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [x86] Unify semaphore_32.S and rwlock_64.S |
| |
On 01/20/2010 11:49 AM, Christoph Lameter wrote: > On Tue, 19 Jan 2010, H. Peter Anvin wrote: > >> Could you do this in the standard sequencing for unification patches: >> first patch the two pieces of code so they are identical, and then >> mechanically unifying them? Otherwise it's almost impossible to see >> what has changed. > > Hmmm... Okay I better do that on top of your patches then. > >>> This is also a good preparatory patch for getting the rwsem XADD stuff >>> to work on x86_64. >> >> Have you tried the tip:x86/rwsem branch (Linus' work with a few >> additions of mine) and had it not work for you? > > No I just saw it. Linus first patch increases the 64/32 bit separation by > creating yet another 64 bit specific file. Can we avoid that and have > code that is shared as much as possible between 32 and 64 bit?
The ABI is completely different between 32 and 64 bits. The stubs avoid keeping track of *those* differences in each and every inline. It might be possible with macros, but there is something that really is very different: for x86-32, there are only three function-clobbered registers, which we pretty much need to use anyway. For x86-64, there are a lot more -- which means that each callsite would end up having gcc generate save/restore code that would be in the fast path. Linus' patch pushes that into the slow path, which seems significantly better to me.
The new file seems like a very good way to deal with the ABI/register set differences here.
> Then there is another that does the %z0 trick while we already have the > proper definitions for that in include/asm/asm.h. Seems that you have > switched to using those. Was that done consistently?
The %z0 trick would have been type-safe. Unfortunately some versions of gcc simply generate incorrect code with it, which is why I switched back to the <asm/asm.h> macros (and yes, I got rid of all the %z's by sheer necessity.)
> Why have a rwsem_count_t when a simple long would do in both cases? Just > make sure that long is consistently used.
The motivation for rwsem_count_t seemed to be making it easier to switch over. I leave it up to Linus to motivate the typedef... I have to say, though, that using a typedef also tells you want the number is for.
> __downgrade_write: Why use the inc trick instead of the add > like in 32 bit? There is not much difference and it results in much > stabler code.
Because you can't do an add with a 64-bit immediate! Yes, we could have loaded it into a register, but that would have required an additional 10-byte(!) instruction for no good reason.
>>> x86_64 gains the FRAME/ENDFRAME handling that i386 has (not sure what the >>> point is of having that there). >> >> Presumably it's so you can have frame pointers everywhere. > > For a small code segment that does not do any subroutine calls?
It's kind of redundant, yes, but that was presumably the logic.
-hpa
| |