The overhead is too high for INVARIANTS. Add a sysctl to optionally
disable the checks.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
sys/vm/vm_map.c | ||
---|---|---|
673 ↗ | (On Diff #56460) | This seems to imply that if INVARIANTS is not set, DIAGNOSTIC is irrelevant. Picking a random file with DIAGNOSTIC in it (kern_clock.c) suggest that this isn't the usual practice. So the #endif for INVARIANTS ought to be before the #ifdef for DIAGNOSTIC, among other rearrangements. |
sys/vm/vm_map.c | ||
---|---|---|
673 ↗ | (On Diff #56460) | So now I've read your related email. I yield. I won't pretend to know what exactly INVARIANTS and DIAGNOSTICS are supposed to mean. Wouldn't you want to include the consistent() function if *either* INVARIANTS or DIAGNOSTICS were defined, and then default vmmap_check to 0 or 1 depending on the settings of INVARIANTS and DIAGNOSTICS? |
sys/vm/vm_map.c | ||
---|---|---|
673 ↗ | (On Diff #56460) | I think that's true in practice: DIAGNOSTIC is basically meant to be an extension of INVARIANTS. The difference is that we want INVARIANTS kernels to be performant enough to be usable as a general-purpose OS, whereas DIAGNOSTIC is mainly useful for running tests or for debugging a specific issue. I can't imagine a scenario where one would configure DIAGNOSTIC without INVARIANTS. It might be more correct to compile the consistency checking under INVARIANT_SUPPORT rather than INVARIANTS, though. (See sys/conf/NOTES for a definition.) I'll note also that the pattern of #ifdef DIAGNOSTIC KASSERT(...); #endif is not uncommon, but KASSERT is a no-op unless INVARIANTS is configured. |