Date: Thu, 21 Jan 1999 22:56:49 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "John S. Dyson" <dyson@iquest.net> Cc: hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change Message-ID: <199901220656.WAA48081@apollo.backplane.com> References: <199901220638.BAA00257@y.dyson.net>
next in thread | previous in thread | raw e-mail | index | archive | help
The problem is that in a heavy paging situation, which can be
brought about by a single memory-hogging process, OTHER
process's pages can wind up in the cache very easily.
Consider tcsh or ssh -- all you have to do is not type for a few
seconds in a heavily paging environment and some critical page
will get thrown into the cache.
The memory-hogging process, on the otherhand, tends to be
allocating new pages or touching very recently allocated
pages. This code does nothing to block the memory hogging
process because those pages are not in the cache.
In my tests, I was able to almost completely lockup a machine
due to a single memory-hogging process. The memory hogging process
caused the other processes to go into VM sleep in the code below.
At *bset*, the other processes were able to page in a single page
once a second or so... no where near enough to make them runnable
long enough to be useable.
Additionally, by sleeping, these process's pages then became eligable
for getting thrown back into the cache.
When I removed this piece of code, the machine remained useable
with four memory hogging processes running.
This code is punishing the wrong processes.
-Matt
:The below code removed has an effect almost the opposite of the
:complaint that it seems have remedied by removing it. This
:code snippet (which was very carefully thought out) provides
:a punishment for a process that is grabbing pages from the cache
:queue, and allows for THAT process to block, without loosing that
:page that is needed. Other processes will be runnable, if they
:have their needed memory pages, and not be disturbed. Those
:pages accessed by other runnable processes will not be freed
:by the pageout daemon (due to the stats that it accumulates.)
:
:Remember, that the cache+free counts is the traditional free
:count. This is a way that a process which does massive activations
:of free (cache) pages, that process will be throttled. This will
:also allow the pageout daemon to do the mapped page stats correctly.
:
:Note that previous discussions regarding proper buffer cache mgmt
:of inactive and cache pages (which I came up with a proper solution)
:are not appropriate here, since the buffer cache pages do need to
:be freed with "lower" priority. The wakeup of the daemon here,
:allows the system to catch up with the reactivations. The wakeup
:of the daemon in the buffer cache code is silly because the priority
:of the buffer cache items should most all of the time be lower
:priority, and the sophisticated priority calculations done by the
:pageout daemon become specious there.
:
:This is a *critical* feature, and progressive removal of such features
:will eventually hurt the already pretty good performance of the VM code
:under load.
:
:Please review the comment, because, again, the effect of the code
:removal does NOT IN ANY WAY help the situation that is described (in
:fact, it can make it worse.)
:
:#if 0
: /*
: * Code removed. In a low-memory situation (say, a
: * memory-bound program is running), the last thing you
: * do is starve reactivations for other processes.
: * XXX we need to find a better way.
: */
: if (((queue - fs.m->pc) == PQ_CACHE) &&
: (cnt.v_free_count + cnt.v_cache_count) < cnt.v_free_min) {
: vm_page_activate(fs.m);
: unlock_and_deallocate(&fs);
: VM_WAIT;
: goto RetryFault;
: }
:#endif
:--
:John | Never try to teach a pig to sing,
:dyson@iquest.net | it makes one look stupid
:jdyson@nc.com | and it irritates the pig.
:
:To Unsubscribe: send mail to majordomo@FreeBSD.org
:with "unsubscribe freebsd-hackers" in the body of the message
:
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901220656.WAA48081>