Re: Broken memory management on system with no swap

:This is actually analogous to a problem that is solved in the 4bsd
:scheduler.  The decay is effected by the load average so that all
:processes do not reach the highest priority as a result of a heavily
:loaded system.  The analogous idea being scaling some value based on
:current system load.
:
:What we could do is apply a filter to a raw act count based on memory
:pressure.  I'm not familiar enough with the properties of the act count in
:practice to suggest what that filter should be.  I think this should make
:the system quite dynamic though.  You would require fewer passes for most
:cases eh?
:
:Cheers,
:Jeff

    Well, I don't think that would work as you might expect.  Thrashing
    is a function of memory load which will often have a direct correlation
    with system load (since blocked processes count in the load calculation).
    The act_count algorithm greatly reduces and smooths the effect of
    thrashing.  If you cause pages to be held in the active queue for a 
    shorter period of time based on load you would cause thrashing to 
    occur sooner rather then later, pretty much destroying the whole
    purpose of having act_count in the first place.  

    The degenerate case that might be occuring here is not related
    to act_count holding a page in the active queue too long, because
    act_count is ignored if the pageout daemon has to take a second pass.
    The degenerate case is simply a side effect of the way the pageout
    daemon's algorithm operates which requires a minimum of two passes
    to get a page from the active queue to the free/cache queues.   I will
    also note that heavy page laundering is also defered until the second
    pass (though I think the issue here is unrelated to dirty pages since
    it has been indicated that 'cp' used write() for the test in question
    rather then mmap()).

    Since the second pass is going to happen anyway we need only defer the
    process killing code till then to (hopefully) solve the problem.

					-Matt
					Matthew Dillon 
					<dillon_at_backplane.com>