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. -MattReceived on Sun Apr 20 2003 - 09:28:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:04 UTC