Date: Thu, 27 Jun 1996 04:03:13 +0200 (MET DST) From: Juergen Lock <nox@jelal.hb.north.de> To: davidg@root.com Cc: jhay@mikom.csir.co.za, stable@FreeBSD.org Subject: Re: lockups. Message-ID: <199606270203.EAA00559@saturn.hb.north.de> In-Reply-To: <199606260255.TAA12927@root.com> from David Greenman at "Jun 25, 96 07:55:34 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman writes:
>...
> >> difference that you're describing. Change the #if 0 to a #if 1 at the end of
> >> /sys/vm/vm_pageout.c.
> >
> >Thats just what i did, and i put back the remove-cached-objects-that-
> >have-no-RSS code below the #if 0'd part. (havent tried the #if 1 alone)
>
> The other code that was removed has always been outside the while(1) loop,
> so it is NEVER executed.
Oops, didn't even notice that loop had no exit :)
>...
> 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:
Index: vm_pageout.c
===================================================================
RCS file: /home/cvs/cvs/src/sys/vm/vm_pageout.c,v
retrieving revision 1.51.4.8
diff -u -r1.51.4.8 vm_pageout.c
--- vm_pageout.c 1996/06/26 08:19:48 1.51.4.8
+++ vm_pageout.c 1996/06/27 00:49:00
@@ -366,21 +366,23 @@
if (count == 0)
count = 1;
- (*recursion)++;
if (*recursion > 5)
return 0;
if (object->pager && (object->pager->pg_type == PG_DEVICE))
return 0;
+ (*recursion)++;
if (object->shadow) {
if (object->shadow->ref_count == 1)
dcount += vm_pageout_object_deactivate_pages(map, object->shadow, count / 2 + 1, map_remove_only, recursion);
else
vm_pageout_object_deactivate_pages(map, object->shadow, count, 1, recursion);
}
- if (object->paging_in_progress || !vm_object_lock_try(object))
+ if (object->paging_in_progress || !vm_object_lock_try(object)) {
+ (*recursion)--;
return dcount;
+ }
/*
* scan the objects entire memory queue
@@ -461,6 +463,7 @@
p = next;
}
vm_object_unlock(object);
+ (*recursion)--;
return dcount;
}
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
Juergen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606270203.EAA00559>