On Fri, Aug 08, 2014 at 11:38:57AM +0300, Timo Teras wrote:
> > actually commit it. If anyone is interested in this feature, please
> > see if you can find some examples that demonstrate that it measurably
> > improves performance.
> 
> And running my simple test-case of having two threads wake up each
> other using a condition variable, seems to yield noticeable performance
> speed up from private futexes. See at the end of mail for the code.
> 
> The low and high numbers from few test runs are as follows from musl 
> git 4fe57cad709fdfb377060 without and with the futex patch are as
> follows:
> 
> ~/privfutex $ time ~/oss/musl/lib/libc.so  ./test
> count=2516417
> real	0m 2.00s
> user	0m 1.68s
> sys	0m 2.30s
> 
> ~/privfutex $ time ~/oss/musl/lib/libc.so  ./test
> count=2679381
> real	0m 2.00s
> user	0m 1.59s
> sys	0m 2.39s
> 
> Private futexes:
> 
> ~/privfutex $ time ~/oss/musl/lib/libc.so  ./test
> count=3839470
> real	0m 2.00s
> user	0m 1.68s
> sys	0m 1.98s
> 
> ~/privfutex $ time ~/oss/musl/lib/libc.so  ./test
> count=5350852
> real	0m 2.00s
> user	0m 1.66s
> sys	0m 2.32s
> 
> 
> You can see essentially lowered sys time use, and up to doubled
> throughput of wait/wake operations.

I was able to match the relative difference (albeit at about 10% of
the total throughput you got for both versions) on my atom.

I also dug up an old test of mine that shows some difference (1.9s vs
2.2s to run). The original point of this test was to demonstrate that
glibc's non-process-shared condvars are 2-2.5x slower than their
process-shared ones (yes, the opposite of what you would expect; see
bug 13234). The code is attached.

> So I suspect your test case was not measuring right thing. Private
> futexes speed up only specific loads, and this type of pthread_cond_t
> usage would probably be the pattern benefiting most.
> 
> Please reconsidering adding this after addressing the found
> deficiencies stated in the beginning.

Yes, I think you've succeeded in establishing that private futex
support is useful. So now I just need to check for more stupid
mistakes, get it into a form that's ready to commit, and do some
testing between now and the next release. We should do at least one
test with private futexes hard-wired to fail (or just find an old
kernel to test on) to make sure the fallback code is working, too.

Rich