[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Reclaiming vnodes
On Tue Sep 15 2009 at 23:29:59 +0300, Antti Kantee wrote:
> On Tue Sep 15 2009 at 13:28:58 -0400, Thor Lancelot Simon wrote:
> > On Tue, Sep 15, 2009 at 06:21:36PM +0100, David Laight wrote:
> > >
> > > You still have a potential deadlock - or at least a failure if
> > > getnewvnode() cannot actually return a new vnode because none are
> > > free at the exact moment of the allocate request.
> > >
> > > You can't sleep awaiting vnodes because that will deadlock against
> > > the reclaim thread, so a system that is cycling vnodes very quickly
> > > will fail during the allocate.
> > This is what I was trying to get at when we discussed this privately
> > a few weeks ago -- to me it seems like we're just moving the problem
> > around, allowing two threads to deadlock against each other instead
> > of allowing one thread to sleep where it shouldn't.
> ... hmmm... ah, vrele_thread() calls getcleanvnode, not getnewvnode.
> No wonder the patch and the discussion didn't make any sense ;)
Hmm, no, there still was a nagging in my brain that something is not
Since the thread calling getnewvnode does vnalloc(), the only way it
will deadlock is with shortage of memory. The deadlock is there, but
the probability of triggering it is not very high (or at least that's
my guess, since there is no proof from testing).
But now the patch comes across as very shabby and unfinished. At least
the pool cache usage should be updated to match the new usage patterns.
... unless I'm misreading the patch again. Maybe I'll have another
Main Index |
Thread Index |