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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
