Re: Broken memory management on system with no swap

From: Matthew Dillon <dillon_at_apollo.backplane.com>
Date: Sun, 20 Apr 2003 11:28:47 -0700 (PDT)
    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
Received 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