Date: Fri, 14 Dec 2012 16:21:25 -0800 From: Alfred Perlstein <bright@mu.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Adrian Chadd <adrian@freebsd.org>, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, svn-src-all@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, Andriy Gapon <avg@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org>, Navdeep Parhar <np@freebsd.org>, svn-src-head@freebsd.org Subject: Re: svn commit: r244112 - head/sys/kern Message-ID: <50CBC285.7060307@mu.org> In-Reply-To: <alpine.BSF.2.00.1212150010160.54345@fledge.watson.org> References: <201212110708.qBB78EWx025288@svn.freebsd.org> <50C9271C.70803@mu.org> <20121213090215.GP97487@FreeBSD.org> <201212141149.07671.jhb@freebsd.org> <alpine.BSF.2.00.1212150010160.54345@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/14/12 4:12 PM, Robert Watson wrote: > On Fri, 14 Dec 2012, John Baldwin wrote: > >> On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff wrote: >>> On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote: A> >>> The problem again is that not all the KASSERTS are inviolable, if >>> you A> want to do a project to split them, then please do, it would >>> really be A> helpful, as for now, they are a mis-mash of >>> death/warnings and there are A> at least three vendors who approve >>> of this as well as 3 long term A> committers that approved my change >>> (not including Adrian). >>> >>> Can you show examples of not inviolable KASSERTs? >> >> There are none. They are all assertions for a reason. However, in >> my experience at several large consumers of FreeBSD, no one wants to >> run with INVARIANTS in production. Not because we don't want panics >> (believe me, Yahoo! gets plenty of panics even with INVARIANTS >> disabled), but because the performance overhead, and redefining >> INVARIANTS into printf doesn't address that at all. > > In the past, FYI, the two major INVARIANTS hits were un-inlining of > locking, and UMA using additional global locking to perform > heavier-weight sanity checking. For me, at least, the former wasn't > such a problem, but the latter was extremely measurable. I have > occasionally wondered if we should have another option name for > heavier-duty sanity checking, as is the case with WITNESS, > SOCKBUF_DEBUG, etc, so that INVARIANTS overhead can be made tolerable > for more real-world installations. As you observe, our invariants > tests are generally things where you catch critical problems in much > more debuggable states, rather than sources of additional fragility, > and it would be great if we could leave more in so that bug reports > were able to contain more information. > > Robert > Yes. The KTR system offers an interesting reference for a model that allows us to make a compile time decision about which areas to trace. There used to be a DIAGNOSTIC option for the more heavy checks, this is either removed or just not used these days. Again, using a mask like KTR might be a win if we bring back the equivalent of heavy weight DIAGNOSTIC option. Often I've been guilty of putting KASSERT(ptr != NULL) checks into the code too. Those are really just to make it less painful when hitting that bug, so instead of having to do a lot of homework to figure out the fault address and line number, I can just get a pretty printed message under INVARIANTS. Maybe those "pretty null checks" need to go under another option, perhaps DIAGNOSTIC, or another .. ??PRETTY_PANIC. Anyhow, I've always been a huge fan of FreeBSD due the additional debugging checks it offered. I was the one that suggested splassert() back in the day when we would continually find issues with spl calls. Additionally I found doing filesystem work a ton easier with DEBUG_VFS_LOCKS under FreeBSD than under Darwin which at the time did not have such a feature. One of my great joys in developing FreeBSD is the flexibility and power it offers us as developers by giving us a huge library of debugging tools. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50CBC285.7060307>