Date: Wed, 4 Feb 1998 07:37:28 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: toor@dyson.iquest.net, current@FreeBSD.ORG Subject: Re: Any feedback on my recent kernel 'fixes' Message-ID: <199802041237.HAA01225@dyson.iquest.net> In-Reply-To: <199802041205.EAA00926@rah.star-gate.com> from Amancio Hasty at "Feb 4, 98 04:05:26 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Amancio Hasty said: > > Just finished building xemacs20 on my pentium on a nfs partition previously > the system would lock up solid. I didn't have X running this time nor the > previous times which the system used to crashed while building xemacs. > > For sure I owed you a beer ! > Great feedback. I think that there is still a bug lurking, but the worst is likely over. There is still a problem that can manifest itself on heavily (memory) loaded systems. It appears to have something to do with vnode rundown or with object collapsing. However, I don't think larger systems (>= 64MB) should often have problems. I am working on the still-existing problem aggressively. I can easily reproduce the problem on small (8MB) systems, with PPro processors, using one of my FreeBSD regression tests. One of the problems that occurred (and it was procedural on my part), was that I quit testing small memory configs with my regression tests. I am doing that again... Sorry!!! There have indeed been bona-fide problems with the swap pager along with other pieces, and the system should be much more stable (as it is for Amancio) for most people now. For those who are a little less intrepid, I suggest waiting 2 more days (until some more minor fixes go in.) Two more things are going to happen to the VM code over the next 2 days. 1) Improve the allocation of VM pages for internal kernel usage. There are too many ad-hoc page allocators, and I already have some cleaner, more consistant, easier to debug/control code ready. 2) Fix an object rundown problem, that appears to be manifested by heavily memory loaded systems. The issue appears to be due to improper memory object reuse after being freed, and can be easily reproduced by a regression test that has atypical (and stressful) program VM behavior. After this, I hope to keep the low-level VM code stable for a while, so we all can work more effectively on some higher level (feature) issues that have had to have been deferred. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802041237.HAA01225>