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

[Pawel Jakub Dawidek]

Post by 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?

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.

[Warner Losh]

Post by Warner Losh

Post by Warner Losh
Greetings,
Many of the performance eating features are exported via some kind of

sysctl, usually

Post by Warner Losh
patterned after the case of witness as debug.foo. INVARIANTS isn’t one

of those

Post by Warner Losh
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

Post by Warner Losh
isn’t a facility that people can use.
If you include the kernel config in the kernel, you can get this

information via

Post by Warner Losh
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

Post by Warner Losh
kernel isn’t built that way and this won’t reflect that. There’s no good

want to include

Post by Warner Losh
that information and is an uncommon use case.
Our use case? We have a raft of test machines. Most run without

INVARIANTS since

Post by Warner Losh
we want to characterize the performance of the release under test. Some

are running

Post by Warner Losh
INVARIANTS since we want to test the robustness as well, even at the

expense of

Post by Warner Losh
some performance. To ensure we don’t accidentally include INVARIANTS

systems

Post by Warner Losh
in the performance number, we’ve adding a key to an internal database

that’s driven

Post by Warner Losh
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

[Pawel Jakub Dawidek]

Post by Warner Losh

Post by Warner Losh

Post by Warner Losh
Greetings,
Many of the performance eating features are exported via some kind of

sysctl, usually

Post by Warner Losh
patterned after the case of witness as debug.foo. INVARIANTS isn’t one

of those

Post by Warner Losh
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

Post by Warner Losh
isn’t a facility that people can use.
If you include the kernel config in the kernel, you can get this

information via

Post by Warner Losh
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

Post by Warner Losh
kernel isn’t built that way and this won’t reflect that. There’s no good

want to include

Post by Warner Losh
that information and is an uncommon use case.
Our use case? We have a raft of test machines. Most run without

INVARIANTS since

Post by Warner Losh
we want to characterize the performance of the release under test. Some

are running

Post by Warner Losh
INVARIANTS since we want to test the robustness as well, even at the

expense of

Post by Warner Losh
some performance. To ensure we don’t accidentally include INVARIANTS

systems

Post by Warner Losh
in the performance number, we’ve adding a key to an internal database

that’s driven

Post by Warner Losh
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.

[Warner Losh]

Post by Pawel Jakub Dawidek

Post by Warner Losh

Post by Warner Losh

Post by Warner Losh
Greetings,
Many of the performance eating features are exported via some kind of

sysctl, usually

Post by Warner Losh
patterned after the case of witness as debug.foo. INVARIANTS isn’t one

of those

Post by Warner Losh
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

Post by Warner Losh
isn’t a facility that people can use.
If you include the kernel config in the kernel, you can get this

information via

Post by Warner Losh
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

Post by Warner Losh
kernel isn’t built that way and this won’t reflect that. There’s no good

want to include

Post by Warner Losh
that information and is an uncommon use case.
Our use case? We have a raft of test machines. Most run without

INVARIANTS since

Post by Warner Losh
we want to characterize the performance of the release under test. Some

are running

Post by Warner Losh
INVARIANTS since we want to test the robustness as well, even at the

expense of

Post by Warner Losh
some performance. To ensure we don’t accidentally include INVARIANTS

systems

Post by Warner Losh
in the performance number, we’ve adding a key to an internal database

that’s driven

Post by Warner Losh
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