cvs commit: src/sys/alpha/alpha pmap.c src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c src/sys/vm vm_page.c

[Robert Watson]

On Thu, 29 Jul 2004, Pawel Jakub Dawidek wrote:

> Hmm, why? Code seems to be very simple, I would even risk: simpler than
> when lock is obtained at first time (but still one atomic operation...).
> I'm not saying here that you don't know what you're talking about, I'm
> just looking for an explanation.

An uncontended mutex acquire is one atomic cmpset and one dereference to
curthread in an inline/macro.

A recursed mutex operation performs the atomic operation, but finds the
lock is already owned, so falls back into _mtx_lock_sleep(), a function.
That function then re-dereferences curthread (optimization opportunity),
calls mtx_owned(), which re-dereferences curthread again (optimization
opportunity), increment the recursion counter as a regular integer
operation, and use an atomic operation to set the MTX_RECURSED flag.

I.e., don't recurse except in unusual cases.  It looks like we can
optimize out two uses of curthread though, which might lighten the cost of
recursion.  While most of our locking doesn't do recursion, Giant can and
does recurse and it might help to do that optimization.

I found that eliminating an extra curthread dereference from
critical_enter()/critical_exit() made a noticeable difference for UP
kernel-intensive benchmarks, FWIW.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Principal Research Scientist, McAfee Research