uma dbg: flexible size for slab debugfree bitset too

[rlibby]

Summary

Recently (r355315) the size of the struct uma_slab bitset field us_free
became dynamic instead of conservative. Now, make the debugfree set
size dynamic too. The debugfree set is INVARIANTS-only, so in fact we
don't care too much about the space savings that results from this, but
enabling minimally-sized slabs on INVARIANTS builds is still important
in order to be able to test new slab layouts effectively.

Test Plan

kyua test -k /usr/tests/sys/sys/Kyuafile

[jeff]

This is good.

sys/vm/uma_core.c

1210 ↗

(On Diff #65487)

I personally try to avoid extra #ifdefs

This could be written BIT_ZERO(keg->uk_ipers, slab_debugfree(slab, keg)));

1495 ↗

(On Diff #65487)

This reads as if it's going to debug a free to a slab. Not return the debug bits. I would rename for clarity. We also call things _dbg_ elsewhere. So it could be slab_dbg_bits().

[rlibby]

sys/vm/uma_core.c

1210 ↗

(On Diff #65487)

Yes... this is actually how I got into the bitset.h rabbit hole, noting that the the BIT_ZERO(_s, p) argument p is evaluated in the loop. We could just hope the compiler sorts it out? Or help the compiler by marking slab_debugfree() as inline ... and __pure? I guess even if the compiler is dumb the effect is not too bad here.

1495 ↗

(On Diff #65487)

Yeah, I like that better too. Will rename.

[rlibby]

jeff feedback

[markj]

sys/vm/uma_core.c

1494 ↗

(On Diff #65489)

Missing parens around the return value.

sys/vm/uma_int.h

276 ↗

(On Diff #65489)

We tend to use C11 _Static_assert() in new code. I don't have any real feelings one way or the other.

[rlibby]

markj feedback

[rlibby]

sys/vm/uma_int.h

276 ↗

(On Diff #65489)

I find it a bit uglier, but all right.