On Fri, 1 Aug 2003, Don Bowman wrote: > > > On Tue, 29 Jul 2003, Don Bowman wrote: > > > > > From: Don Bowman [mailto:[EMAIL PROTECTED] > > > > > > > > From: Robert Watson [mailto:[EMAIL PROTECTED] > > > > > 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 ... _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
