Date: Wed, 26 Jun 1996 19:32:14 -0700 From: David Greenman <davidg@root.com> To: Juergen Lock <nox@jelal.hb.north.de> Cc: jhay@mikom.csir.co.za, stable@FreeBSD.org Subject: Re: lockups. Message-ID: <199606270232.TAA00264@root.com> In-Reply-To: Your message of "Thu, 27 Jun 1996 04:03:13 %2B0200." <199606270203.EAA00559@saturn.hb.north.de>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Yes, that appears to be the problem. We're going to turn this code back on >> after putting some controls on it to make sure it doesn't cause stability >> problems. John will have a fix soon (if not already), so please install the >> fix and get back to us ASAP. > > updated the kernel again (got vm_pageout.c 1.51.4.8, and had to update >ipfw(8) as well btw), problem was back. maybe a little less serious but >still bad enough. anyway after some experimenting i finally thought >what if i just fixed the recursion counting... and yes, now it seems >to behave itself again: (patch deleted to save space) > of course because of the limited recursion i still have some swapped-out >processed with rss > 0 but thats apparently not enough critical mass >anymore to trigger the thrashing, at least on this system. > > (or maybe make the recursion limit (the 5) configurable and allocate >stack accordingly, would that be possible? i guess then that should be >good enough until a `real' fix is ready...) > > does that help? cheers Yes, this does help. I've also discovered the true nature of the problem in the meantime - swapping was broken. Basically, the pmap layer always returns "TRUE" for the upages (kernel stack and u area) and while swapout() made the pages pageable, they were never completely removed from the address space. The result was that the pages could never be made clean and would be continually paged out. This caused the pagedaemon to loop endlessly in some cases while memory remained in short supply. The problem isn't noticed when the RSS limiting code is enabled because it (apparantly) has the side effect of more forcefully removing the process pages and thus side-steps the problem. I've attached a quick hack to "fix" the problem. We may fix this problem differently in the release, but this should be adequate for now. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project Index: vm_glue.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_glue.c,v retrieving revision 1.20.4.4 diff -c -r1.20.4.4 vm_glue.c *** vm_glue.c 1996/02/22 11:10:08 1.20.4.4 --- vm_glue.c 1996/06/27 02:14:36 *************** *** 506,511 **** --- 506,514 ---- ptaddr = trunc_page((u_int) vtopte(kstack)); vm_map_pageable(map, ptaddr, ptaddr + NBPG, TRUE); + pmap_remove(vm_map_pmap(map), (vm_offset_t)kstack, + (vm_offset_t)kstack + UPAGES * PAGE_SIZE); + p->p_flag &= ~P_SWAPPING; p->p_swtime = 0; }
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606270232.TAA00264>