Re: [patch 00/21] mutex subsystem, -V14

this is version 14 of the generic mutex subsystem, against v2.6.15.

The patch-queue consists of 21 patches, which can also be downloaded from:

  http://redhat.com/~mingo/generic-mutex-subsystem/


Took a glance at this on ppc64. Would it be useful if I contributed an arch specific version like arm has? We'll either need an arch specific version or have the generic changed.

Anyway, here is some disassembly of some of the code generated with my comments:

c00000000049bf9c <.mutex_lock>:
c00000000049bf9c: 7c 00 06 ac eieio
c00000000049bfa0: 7d 20 18 28 lwarx r9,r0,r3
c00000000049bfa4: 31 29 ff ff addic r9,r9,-1
c00000000049bfa8: 7d 20 19 2d stwcx. r9,r0,r3
c00000000049bfac: 40 c2 ff f4 bne+ c00000000049bfa0 <.mutex_lock+0x4>
c00000000049bfb0: 4c 00 01 2c isync
c00000000049bfb4: 7d 20 4b 78 mr r0,r9
c00000000049bfb8: 78 09 0f e3 rldicl. r9,r0,33,63
c00000000049bfbc: 4d 82 00 20 beqlr
c00000000049bfc0: 4b ff ff 58 b c00000000049bf18 <.__mutex_lock_noinline>

The eieio is completly unnecessary, it got picked up from atomic_dec_return (Anton, why is there an eieio at the start of atomic_dec_return in the first place?).

Ignore the + on the bne, the disassembler is wrong, it is really a -

c00000000049bfc4 <.mutex_unlock>:
c00000000049bfc4: 7c 00 06 ac eieio
c00000000049bfc8: 7d 20 18 28 lwarx r9,r0,r3
c00000000049bfcc: 31 29 00 01 addic r9,r9,1
c00000000049bfd0: 7d 20 19 2d stwcx. r9,r0,r3
c00000000049bfd4: 40 c2 ff f4 bne+ c00000000049bfc8 <.mutex_unlock+0x4>
c00000000049bfd8: 4c 00 01 2c isync
c00000000049bfdc: 7d 20 07 b4 extsw r0,r9
c00000000049bfe0: 2c 00 00 00 cmpwi r0,0
c00000000049bfe4: 4d 81 00 20 bgtlr
c00000000049bfe8: 4b ff ff 40 b c00000000049bf28 <.__mutex_unlock_noinline>

That eieio should be an lwsync to avoid data corruption. And I think the isync is superfluous.

Ditto the disassembler being wrong about the + vs -.
-
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/

Relevant Pages

  • Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix
    ... I've noticed arm and parisc, luckily no arm/parisc user tried my tree ... some arch was setting a max file offset multiple in the mmap API to ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: [patch 00/21] mutex subsystem, -V14
    ... > an arch specific version like arm has? ... We'll either need an arch ... feel free to implement an assembly mutex fastpath, ... > The eieio is completly unnecessary, ...
    (Linux-Kernel)
  • Re: [PATCH] I/O space write barrier
    ... > Ideally, it would be eieio, and the eieio in each ... most driver developers will be on x86 boxes. ... Well, I won't pretend to understand how the PPC ordering rules work, so I'll ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: [PATCH] I/O space write barrier
    ... For ppc, eieio is ... instead of fresh assembly code. ... it were some sort of cache push operation. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: [PATCH] I/O space write barrier
    ... >> but I suspect that nearly all drivers would break. ... if it's covered than mmiowbcan just be empty for ppc. ... Ideally, it would be eieio, and the eieio in each ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)