Date: Wed, 11 Aug 1999 14:16:59 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: David Greenman <dg@root.com> Cc: Charles Randall <crandall@matchlogic.com>, freebsd-hackers@FreeBSD.ORG, Oleg Derevenetz <oleg@oleg.sani-c.vrn.ru> Subject: Re: mmap bug Message-ID: <199908112116.OAA77941@apollo.backplane.com> References: <199908111819.LAA26998@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> :>He's trying to ask if this is a problem with the code in question or 3.2R's :>mmap. : : That's better. It appears to be a classic resource related deadlock that :is caused by the VFS code needing pages in order to page things out (and thus :free up pages), but is unable to since no memory is available. : Matt Dillon was working on deadlocks like this in -current awhile back and :it would be interesting to know if the hang occurs there as well. I don't :have a -current machine at the moment so I can't test it myself. : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org :Creator of high-performance Internet servers - http://www.terasolutions.com The problem can occur in both STABLE and CURRENT. I ran the test program on a CURRENT system artificially limited to 64MB of ram. It locked it up instantly. This is because we map clean R+W pages as R+W. Thus we do not take a fault when the process dirties a pages underlying a map, so we do not know that it has been dirtied until it is far too late. When we run out of pages, the system daemons lockup in the VFS subsystem when the filesystem tries to read or write metadata. One solution would be to map clean R+W pages RO and force a write fault to occur, allowing the system to recognize that there are too many dirty pages in vm_fault before it is too late and flush some of them. The downside of this is that, of course, we take unnecessary faults. Another solution might be to reorganize the emergency page reserve to operate based on a P_ flag in the process structure, so VFS routines that normally block when memory is low are allowed to proceed when called from system processes. I'll try persuing the second idea. -Matt Matthew Dillon <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908112116.OAA77941>