lkml.org 
[lkml]   [2010]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2010-01-20 21:17    [W:0.061 / U:1.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site