svn commit: r244112 - head/sys/kern

[Robert Watson]

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