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