From owner-freebsd-bugs Sat Jun 24 18:15:21 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA02932 for bugs-outgoing; Sat, 24 Jun 1995 18:15:21 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA02926 for ; Sat, 24 Jun 1995 18:15:19 -0700 Received: from corbin.Root.COM (corbin [198.145.90.18]) by Root.COM (8.6.11/8.6.5) with ESMTP id SAA01382; Sat, 24 Jun 1995 18:15:19 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id SAA00280; Sat, 24 Jun 1995 18:15:42 -0700 Message-Id: <199506250115.SAA00280@corbin.Root.COM> To: Matt Dillon cc: bugs@freebsd.org Subject: Re: more on the paging thing In-reply-to: Your message of "Sat, 24 Jun 95 16:25:27 PDT." <199506242325.QAA16868@shell1.best.com> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 24 Jun 1995 18:15:42 -0700 Sender: bugs-owner@freebsd.org Precedence: bulk > Hmm... well, here's the problem I see: > > * shell machine, 130 users on line, sitting at around a load of 8 > * vmstat shows free pages steadily declining > * system does a spurt of paging > * 30-50 processes suddenly go into the 'w' column, the 'r' column > jumps to 30 as well, for about 4 seconds > * things slowly smooth out again .. back to normal after 4 seconds > > * repeat 30 seconds later... > > The problem is that whenever this occurs, EVERYONE gets glitched... > everything comes to a screaming stop for a few seconds, then picks up > again. Not good... > Obviously, some heavily used pages are being paged out when they should > not be! It may seem that way, but things in this area can be quite misleading. I think the problem has to do with swapping, not the regular paging algorithm. If you're game, I think I'd like to try disabling swapping on your system and see if the problem improves. A diff is attached for this purpose. There is also a chance that this problem is another manifestation of pages being cleaned even if memory isn't really very tight; I hesitate calling this behavior a bug, but it might be good to look at it more carefully. > The question is how to solve the problem. The system is not paging > heavily. It's got 128MB of ram and nominally about 12M free, which > drops steadily over 30 seconds to 2M or less, then the system does a > spurt of paging for a few seconds which bumps the free back up to 12M, > and so on.... What I would like to do is lock the pages associated > with the c shared library and a few critical executable text areas > (telnet, rlogind, and possibly tcsh) into memory. Keep in mind that "real" free memory isn't really the complete picture. In post-FreeBSD 2.0, there is another category of free memory that is /almost/ free. We call this "VM cache pages". These pages are clean and not mapped in any process. They can be freed at anytime except during interrupts. They generally contain cached file data, but may contain parts of executables. "vmstat " hasn't yet been updated to include cache pages, but this information is available with "vmstat -s". -DG Index: vm_pageout.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_pageout.c,v retrieving revision 1.51 diff -c -r1.51 vm_pageout.c *** 1.51 1995/05/30 08:16:18 --- vm_pageout.c 1995/06/25 01:13:41 *************** *** 747,752 **** --- 747,753 ---- wakeup((caddr_t) &vfs_update_wakeup); } } + #if 0 /* * now swap processes out if we are in low memory conditions */ *************** *** 755,760 **** --- 756,762 ---- vm_pageout_req_swapout = 1; vm_req_vmdaemon(); } + #endif } if ((cnt.v_inactive_count + cnt.v_free_count + cnt.v_cache_count) <