kernel deadlock

[The Hermit Hacker]

On Fri, 1 Aug 2003, Don Bowman wrote:

>
> > On Tue, 29 Jul 2003, Don Bowman wrote:
> >
> > > From: Don Bowman [mailto:don at sandvine.com]
> > > >
> > > > From: Robert Watson [mailto:rwatson at freebsd.org]
> > > > > On Tue, 29 Jul 2003, Dave Dolson wrote:
> > > > >
> > > > > > To follow up, I've discovered that the system has
> > > > exhausted its "FFS
> > > > > > node" malloc type.
> > > >  ...
> > > > >
> > > > > Some problems with this have turned up in -CURRENT on
> > large-memory
> > > > > machines where some of the scaling factors have been off.  In
> > > >
> > > > We currently have kern.maxvnodes=70354 set (automatically
> > > > scaled). This
> > > > is a 1GB box.
> > > >
> > > > I will try re-running the test with less.
> > > >
> > > > when it hits kern.maxvnodes, what will it do?
> > >
> > > After applying the fixes from RELENG_4 for kern/52425,
> > > I can still easily reproduce this hang without low memory.
> > > Further debugging shows that vnlru process is waiting on
> > > vlrup. This line is shown below. ie vnlru_nowhere is being
> > > incremented ever 3 seconds.
>
> So what is happening here is that vnlru wakes up, runs through,
> and there is nothing to free, so it goes back to sleep having
> freed nothing. The caller doesn't wake up. There's no vnodes
> to free, and everything in the system locks up.
>
> One possible solution is to make vnlru more aggressive, so
> that before giving up, it tries to free pages that have
> many references etc (which it currently skips).
> Another option is to have it simply bump the kern.maxvnodes
> number and wake up the process which called it.
>
> Suggestions?
>

check out 4.8-STABLE, which Tor.Egge(sp?) made modifications to the vnlru
process that sound exactly what you are proposing ...