Date: Sat, 15 Dec 2012 00:12:31 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: Adrian Chadd <adrian@freebsd.org>, Alfred Perlstein <bright@mu.org>, src-committers@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: <alpine.BSF.2.00.1212150010160.54345@fledge.watson.org> In-Reply-To: <201212141149.07671.jhb@freebsd.org> References: <201212110708.qBB78EWx025288@svn.freebsd.org> <50C9271C.70803@mu.org> <20121213090215.GP97487@FreeBSD.org> <201212141149.07671.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1212150010160.54345>