exporting INVARIANTS easily

[Warner Losh]

On Mon, Sep 7, 2015 at 3:29 PM, Pawel Jakub Dawidek <pjd at freebsd.org> wrote:

> On Wed, Aug 26, 2015 at 11:20:06AM -0600, Warner Losh wrote:
> > Greetings,
> >
> > Many of the performance eating features are exported via some kind of
> sysctl, usually
> > patterned after the case of witness as debug.foo. INVARIANTS isn’t one
> of those
> > features.
> >
> > https://reviews.freebsd.org/D3488
> >
> > implements debug.invariants. Please comment.
> >
> > I’d thought about adding it to the kern.features sysctl, but thought
> better of it since it
> > isn’t a facility that people can use.
> >
> > If you include the kernel config in the kernel, you can get this
> information via
> >       config -x | grep INVARIANTS
> > but not all kernels do that. This is more robust.
> >
> > I also know that you can load some modules compiled INVARIANTS when the
> base
> > kernel isn’t built that way and this won’t reflect that. There’s no good
> want to include
> > that information and is an uncommon use case.
> >
> > Our use case? We have a raft of test machines. Most run without
> INVARIANTS since
> > we want to characterize the performance of the release under test. Some
> are running
> > INVARIANTS since we want to test the robustness as well, even at the
> expense of
> > some performance. To ensure we don’t accidentally include INVARIANTS
> systems
> > in the performance number, we’ve adding a key to an internal database
> that’s driven
> > off this sysctl.
> >
> > Comments?
>
> As long as the ultimate goal is to have INVARIANTS in GENERIC I'm all
> for it! I use to run even production machines with INVARIANTS, which was
> helpful to catch VirtualBox's kernel memory corruption, but we've moved
> to GENERIC since I wanted to use freebsd-update. Having INVARIANTS in
> GENERIC would be great.


That's not my goal. And I doubt my employer would run it in their
kernel config because it costs too much in bandwidth when we're
streaming all that video people binge watch.

Warner