Is MTX_CONTESTED evil?
Seigo Tanimura
tanimura at tanimura.dyndns.org
Mon Mar 15 21:22:01 PST 2004
_mtx_unlock_sleep() currently wakes up only one thread being blocked,
and leaves MTX_CONTESTED on a mutex. According to Solaris Internals,
that strategy adds an overhead to check for MTX_CONTESTED on a mutex,
even though it is not held by any thread. The thread waken up cannot
grab the mutex immediately by _obtain_lock() and have to go through
_mtx_lock_sleep(). The penalty tends to be large for a mutex with a
high contention, and we have at least one of such a mutex - Giant.
What would it be like if we axed MTX_CONTEST and let
_mtx_unlock_sleep() wake up all of the blocked threads?
--
Seigo Tanimura <tanimura at tanimura.dyndns.org> <tanimura at FreeBSD.org>
More information about the freebsd-arch
mailing list