[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140809015013.GX1674@brightrain.aerifal.cx>
Date: Fri, 8 Aug 2014 21:50:13 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] private futex support
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
View attachment "cvb2.c" of type "text/plain" (1143 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
