On Dec 30, 2013, at 5:23 AM, [email protected] wrote: > I noticed that the OSX version of the jemalloc uses spin locks and decided to > implement support for the pthread spin locks that can be used in Linux. At > least in my case there is huge benefit because I run a single thread in a > specific core that has not that much other activity and pthread mutex lock > contention seems to always schedule the thread away from execution, so spin > locking seems to give more stable result while adding bit more CPU load. Most > likely in more general case this would not be wanted, because there would be > more threads/processes running on same core and thus the scheduling might > give execution time for some other important threads like the one having the > lock taken. > > What do you think, is this something that could be merged to the upstream? My > patch implements new configure script option --enable-pthread-spinlock that > turns on the pthread spin lock i.e. the spin locks are not used by default > because of the scheduling benefit with normal use.
The only reason jemalloc uses spinlocks on OS X is that normal pthread mutex creation uses malloc() internally, and that causes bootstrapping issues. Under all the real-world scenarios I've examined, mutex contention is negligible. Furthermore, on Linux jemalloc uses adaptive mutexes, which IIRC spin before blocking. Do you have an application for which your patch makes a significant difference? Thanks, Jason _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
