From owner-freebsd-hackers Thu Jan 21 22:57:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA00259 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 22:57:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA00254 for ; Thu, 21 Jan 1999 22:57:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id WAA48081; Thu, 21 Jan 1999 22:56:49 -0800 (PST) (envelope-from dillon) Date: Thu, 21 Jan 1999 22:56:49 -0800 (PST) From: Matthew Dillon Message-Id: <199901220656.WAA48081@apollo.backplane.com> To: "John S. Dyson" Cc: hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change References: <199901220638.BAA00257@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message