Date: Wed, 27 Feb 2002 09:33:48 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: peter@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: you broke current in some weird way... etc Message-ID: <200202271733.g1RHXmh27846@apollo.backplane.com> References: <95075.1014756753@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
:date: 2002/02/27 09:51:32; author: peter; state: Exp; lines: +245 -191
:Back out all the pmap related stuff I've touched over the last few days.
:There is some unresolved badness that has been eluding me, particularly
:affecting uniprocessor kernels. Turning off PG_G helped (which is a bad
:sign) but didn't solve it entirely. Userland programs still crashed.
I'm just going to use this opportunity to plug the concept of temporary
sysctl-instrumentation for a commit like this. I'm not saying that
sysctl instrumentation will catch such problems every time, or that it
is appropriate in all cases, but if you had done it and turning off the
sysctl had stopped the crashes you could have simply committed a change
to the sysctl default. This would have stopped the breakage in the
general community and give you time to track the problem down with the
aid of those specific developers who reported the problem.
This rather then backing out the entire commit which creates additional
disruption and makes it difficult to solicit help from the people
reporting the problem.
I'm just going to contrast this with my critical_*() commit - the whiners
that forced the backout aside, if the commit had stayed in and through
normal developer testing was found to be buggy, the fact that it is
instrumented would have (1) made validation of the bug easy, (2) allowed
developers to get back to a working system without having to back anything
out, and (3) it DID greatly improve my ability to follow-up with Ian
to track the bug down, again without him having to back anything out.
The length of time one keeps the instrumentation is heavily dependant on
the feature being instrumented. For critical_*() I expect to keep the
instrumentation intact only for a two or three months. For Giant wrappers
I intend to keep it intact through the 5.0 release. Another example would
be something like vfs.vmiodirenable. This sysctl allowed three or four
developers to track down VMIO-backed directory bugs over a period of a
year in stable without effecting our userbase. I recently made it the
default and I'll probably remove the instrumentation entirely within
the next two releases or so. I can't even begin guessing how much time
and effort that sysctl has saved me.
It's a win-win proposition. just a thought.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202271733.g1RHXmh27846>