From owner-freebsd-hackers Thu Jan 21 22:39:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA28370 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 22:39:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA28363 for ; Thu, 21 Jan 1999 22:39:11 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 22637 invoked from network); 22 Jan 1999 06:39:00 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 22 Jan 1999 06:39:00 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id BAA00257; Fri, 22 Jan 1999 01:38:57 -0500 (EST) Message-Id: <199901220638.BAA00257@y.dyson.net> Subject: Error in vm_fault change To: hackers@FreeBSD.ORG, dillon@apollo.backplane.org Date: Fri, 22 Jan 1999 01:38:57 -0500 (EST) From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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