On Fri, Oct 16, 2009 at 11:02:48AM +0100, Matthias Scheler wrote: > On Fri, Oct 16, 2009 at 11:58:08AM +0200, Adam Hamsik wrote: > > > That sounds like a better approach than your first suggestion because > > > it will (hopefully) avoid the overhead and delay in most cases. > > > > That approach seems like a hack to me because MUTEX_HELD should not be > > used for locking decisions, but we are doing the same in 1 and 3. > > Yes, indeed, I missed that hitch. Can the same be achieved by > using mutex_tryenter()? It depends how your mutex_tryenter() behaves in case of recursive call. The code in FreeBSD takes care of three cases: 1. The lock is already held, because reclaim is called from a code-path that obtained the lock for us. Thanks to do we can just reclaim here. 2. The lock isn't held, but we were able to obtain it with trylock. We can reclaim here. 3. The lock isn't held and we were not able to obtain it with trylock. We defer reclamation to a taskq. In two out of three cases we can reclaim immediately. Of course it's not perfect to use mutex_held() for locking decisions, but I don't think you want to modify VFS to pass some additional parameter, which will tell you this. Another option is to recurse on a lock, but recursive locks are always evil and in this case we only "emulate" recursion in one place using mutex_held(). There is similar not BSD-specific deadlock which was fixed by introduction of VN_RELE_ASYNC(). -- Pawel Jakub Dawidek http://www.wheel.pl pjd%FreeBSD.org@localhost http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
Attachment:
pgpybZrQefjKt.pgp
Description: PGP signature