Messages in this thread | | | Subject | PATCH futex on fusyn (Was: RE: [RFC/PATCH] FUSYN Realtime & robust mutexes for Linux, v2.3.1) | Date | Wed, 18 Aug 2004 19:07:26 -0700 | From | "Perez-Gonzalez, Inaky" <> |
| |
> From: Ingo Molnar [mailto:mingo@elte.hu] > > i believe the key to integration of this feature is to try to make it > used by normal (non-RT) apps as much as possible. I.e. try to make > current futexes a subset of fusyn.c and to merge the two APIs if > possible (essentially renaming your fusyn.c to futex.c and implementing > the futex API). Is this possible without noticeable performance overhead > (and without too many special-cases)?
Ok, here we go with a first cut -- sorry for the time it took, came back from vacation and had the usual big-pile-o-crap waiting for me.
There are two patches, first one, fusyn-2.3.1-00-misc-requeue (-p1) contains the few fixes on top of 2.3.1 that are needed to be able to map futexes on top of fusyn. Mainly is adding fuqueue_requeue() [before I only had fulock requeue from a fuqueue], splitting sys_ufuqueue_wake() and fixing some stupid mistakes.
Second patch, fusyn-2.3.1-01-futex-switch.patch implements a sysctl-based futex switch. Echo 1 to /proc/sys/kernel/futex_uses_fusyn and new futexes will be based on fusyns. Echo 0 and we are back to normal.
caveat emperors:
- 01-futex-switch is a crappy quick hack. If there where applications waiting on futexes and you flip the switch, they will wait for ever in there... a 'kill -CONT' might help.
- FUTEX_FD is not implemented--too much work for a proof of concept.
- ufuqueue_requeue() is more limited than futex's in that it will always requeue everybody, not just the number of passed waiters. There is a reason for it, and is it is only used for broadcast and broadcast means everybody. It makes it simpler to do it in a O(1) way [that by the way, I had to hack around because it was broken--fix in the works...someday].
So, there are WARN_ONs to catch cases of calls not doing the args as expected--but so far, I haven't caught any.
Performance:
I used my favorite stress microbenchmark, str03 [1] which is a program I stole I don't remember where from that does a lot of conditional variable and mutexing. Running it like:
$ (ulimit -s 32; /usr/bin/time -f %e ./str03 -b 5 -d 5)
creates a good 3900 threads that need to talk among them to finish and communicate via mutexes and condvars.
In my test machine, 2xP3 (Coppermine) 933MHz w/ 2 GiB Ram, I get the average of ten runs as:
Environment Seconds (10 continuous runs averaged) ----------- ------------------- plain NPTL and futexes 0.97 plain NPTL, futexes use fuqueues 1.15 Under RTNPTL, using fulocks 1.48
So using fuqueues instead of fusyns is slightly slower on heavy use--I expected it due to the extra overhead. I am off to do a full Volanomark run, see how it behaves [this takes more time--won't be ready until tomorrow].
Patches inlined below in two following messages. They should also show up at the CVS snapshots that we get at our OSDL site.
[1] http://developer.osdl.org/dev/robustmutexes/fusyn/2.3.1/ rtnptl-test-misc-2.3.tar.gz, in src/
Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault) - 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/
| |