:>
:>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
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message