Date: Thu, 29 Jul 2004 16:03:33 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: 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 Message-ID: <Pine.NEB.3.96L.1040729155850.46374L-100000@fledge.watson.org> In-Reply-To: <20040729195156.GA57678@darkness.comp.waw.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040729155850.46374L-100000>