Re: [PATCH] FUTEX_WAKE_OP (pthread_cond_signal speedup)

[Ingo Molnar <mingo@redhat.com>]

On Tue, 23 Aug 2005, Jakub Jelinek wrote:

> Hi!
> 
> ATM pthread_cond_signal is unnecessarily slow, because it wakes one
> waiter (which at least on UP usually means an immediate context switch
> to one of the waiter threads).  This waiter wakes up and after a few
> instructions it attempts to acquire the cv internal lock, but that lock
> is still held by the thread calling pthread_cond_signal.  So it goes
> to sleep and eventually the signalling thread is scheduled in, unlocks
> the internal lock and wakes the waiter again.


> With the following benchmark on UP x86-64 I get:
> 
> for i in nptl-orig nptl-requeue nptl-wake_op; do echo time elf/ld.so --library-path .:$i /tmp/bench; \
> for j in 1 2; do echo ( time elf/ld.so --library-path .:$i /tmp/bench ) 2>&1; done; done
> time elf/ld.so --library-path .:nptl-orig /tmp/bench
> real 0m0.655s user 0m0.253s sys 0m0.403s
> real 0m0.657s user 0m0.269s sys 0m0.388s
> time elf/ld.so --library-path .:nptl-requeue /tmp/bench
> real 0m0.496s user 0m0.225s sys 0m0.271s
> real 0m0.531s user 0m0.242s sys 0m0.288s
> time elf/ld.so --library-path .:nptl-wake_op /tmp/bench
> real 0m0.380s user 0m0.176s sys 0m0.204s
> real 0m0.382s user 0m0.175s sys 0m0.207s

translation: effective thread switching is now almost twice as fast with
the WAKE_OP extension of the futex interface. Cool!

a detail: many of the futex_atomic_op_inuser() seem to be duplicated
across architectures. Might be worth putting into asm-generic, to avoid
the duplication?

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