Date: Sun, 20 Apr 2003 23:22:34 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: freebsd-current@freebsd.org Subject: Re: Broken memory management on system with no swap Message-ID: <200304210622.h3L6MYPK092346@apollo.backplane.com> References: <20030421013449.V76635-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
: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@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304210622.h3L6MYPK092346>