Broken memory management on system with no swap
Matthew Dillon
dillon at apollo.backplane.com
Sun Apr 20 11:28:49 PDT 2003
Hmm. It sounds like this program is using mmap() to dirty pages and
that the VM system is not flushing them out quickly enough to avoid
running out of memory. This could happen if the program dirties
a significant portion of memory all at once. The pageout daemon would
wind up doing a priority requeue of the dirty pages (line 848 of
vm_pageout.c) and 'miss' flushing any of them out to the filesystem
in the first pass. The result would be that the system would believe
it has run out of memory for a short period of time.
We don't want to disable the requeue code, because doing so would
destroy pageout performance for any other case. The 'pass' variable
was supposed to deal with this case (by forcing the laundering if the
system is unable to find enough pages to free the first time), see
line 848 again. But in looking at the code the big-process-kill sequence
is still run in the first pass (pass == 0), and it probably shouldn't
be run until the second pass (pass != 0).
I suggest changing this:
if ((vm_swap_size < 64 && vm_page_count_min()) ||
(swap_pager_full && vm_paging_target() > 0)) {
To this:
if (pass != 0 &&
((vm_swap_size < 64 && vm_page_count_min()) ||
(swap_pager_full && vm_paging_target() > 0))) {
Assuming this fixes the problem I would request that it be tested in
true out-of-memory situations to ensure that the big-process-kill code
still works properly before comitting it.
-Matt
More information about the freebsd-current
mailing list