tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ZFS vs NetBSD vnode recycling



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



Home | Main Index | Thread Index | Old Index