Re: [patch 00/19] mutex subsystem, -V11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Ingo Molnar <[email protected]> wrote:

> this is version -V11 of the generic mutex subsystem, against v2.6.15.

When compiling for x86 with no mutex debugging, I see:

	(gdb) disas mutex_lock
	Dump of assembler code for function mutex_lock:
	0xc02950d0 <mutex_lock+0>:      lock decl (%eax)
	0xc02950d3 <mutex_lock+3>:      js     0xc02950ef <.text.lock.mutex>
	0xc02950d5 <mutex_lock+5>:      ret    
	End of assembler dump.
	(gdb) disas 0xc02950ef
	Dump of assembler code for function .text.lock.mutex:
	0xc02950ef <.text.lock.mutex+0>:        call   0xc0294ffb <__mutex_lock_noinline>
	0xc02950f4 <.text.lock.mutex+5>:        jmp    0xc02950d5 <mutex_lock+5>
	0xc02950f6 <.text.lock.mutex+7>:        call   0xc029509f <__mutex_unlock_noinline>
	0xc02950fb <.text.lock.mutex+12>:       jmp    0xc02950db <mutex_unlock+5>
	End of assembler dump.

Can you arrange .text.lock.mutex+0 here to just jump directly to
__mutex_lock_noinline? Otherwise we have an unnecessarily extended return

You may not want to make the JS go directly there, but you could have that go
to a JMP to __mutex_lock_noinline rather than having a CALL followed by a JMP
back to a return instruction.

Admittedly, this may not be possible, as you're mixing up C and ASM, but it
would speed things up a little.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux