exporting INVARIANTS easily

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

exporting INVARIANTS easily

Warner Losh
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?

Warner


signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: exporting INVARIANTS easily

Pawel Jakub Dawidek
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.

--
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://mobter.com

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: exporting INVARIANTS easily

Warner Losh
On Mon, Sep 7, 2015 at 3:29 PM, Pawel Jakub Dawidek <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: exporting INVARIANTS easily

Pawel Jakub Dawidek
On Mon, Sep 07, 2015 at 04:18:25PM -0600, Warner Losh wrote:

> On Mon, Sep 7, 2015 at 3:29 PM, Pawel Jakub Dawidek <[hidden email]> 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.
Do you have some numbers handy? I'd be interested in seeing how much
performance drop there is when you have INVARIANTS compiled in, but
debug.invariants set to 0.

--
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://mobter.com

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: exporting INVARIANTS easily

Warner Losh

> On Sep 7, 2015, at 4:48 PM, Pawel Jakub Dawidek <[hidden email]> wrote:
>
> On Mon, Sep 07, 2015 at 04:18:25PM -0600, Warner Losh wrote:
>> On Mon, Sep 7, 2015 at 3:29 PM, Pawel Jakub Dawidek <[hidden email]> 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.
>
> Do you have some numbers handy? I'd be interested in seeing how much
> performance drop there is when you have INVARIANTS compiled in, but
> debug.invariants set to 0.
I don’t have any direct numbers, but the belief is that we’ll see between 10-20%
drop in our peak throughput with an INVARIANTS kernel.

Warner


signature.asc (859 bytes) Download Attachment