Date: Fri, 1 Aug 2003 14:59:37 -0400 From: Don Bowman <don@sandvine.com> To: "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org> Subject: RE: kernel deadlock Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337027420EE@mail.sandvine.com>
next in thread | raw e-mail | index | archive | help
> On Tue, 29 Jul 2003, Don Bowman wrote: > > > From: Don Bowman [mailto:don@sandvine.com] > > > > > > From: Robert Watson [mailto:rwatson@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? --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE045D4D9F7AED4CBFF1B3B813C85337027420EE>