Export some UMA info via sysctl.

[markj]

Summary

These show the total amount of memory used for UMA slabs, and the limit
on such memory.

[dougm]

sys/vm/uma_core.c

148 ↗

(On Diff #58228)

Is uma_kmem_limit also something that ought to be accessed and modified atomically?

151 ↗

(On Diff #58228)

Consider making the initial value of 0 explicit here.

[kib]

sys/vm/uma_core.c

3813 ↗

(On Diff #58228)

Why do you need this atomic ? Esp. since sysctl handler would not use volatile qualification.

[markj]

sys/vm/uma_core.c

148 ↗

(On Diff #58228)

I don't think it's necessary: currently it's set only once, during boot time.

151 ↗

(On Diff #58228)

Hmm, conventionally we omit the explicit zero-initialization when the variable is initialized later (early during boot in this case). For, e.g., a sysctl setting where 0 means off (default) and 1 means on, I would use an explicit initializer of 0.

3813 ↗

(On Diff #58228)

I did it because I removed the volatile qualifier from the var. All of its other accesses are via atomic_* so I prefer to be consistent here.

[dougm]

sys/vm/uma_core.c

148 ↗

(On Diff #58228)

Because uma_set_limit is called only once, during boot time. Maybe a comment somewhere should explain that.

So why initialize to LONG_MAX? Why not just

static unslgned long uma_kmem_limit; /* initialized by uma_set_limit(). */

[markj]

sys/vm/uma_core.c

148 ↗

(On Diff #58228)

I will add a comment.

We initialize to LONG_MAX so that UMA allocations can succeed before uma_set_limit() is called. If it were initialized to zero, such allocations would always fail because uma_avail() would return zero.

[kib]

sys/vm/uma_core.c

3813 ↗

(On Diff #58228)

As I noted, sysctl would not access it as volatile.

[markj]

sys/vm/uma_core.c

3813 ↗

(On Diff #58228)

Sorry, I see. The change is indeed unrelated to my original purpose of adding sysctls. I will commit that part separately.

[markj]

Add a comment for uma_kmem_limit.

[markj]

sys/vm/uma_core.c

148 ↗

(On Diff #58228)

Sorry, I misremembered. The allocations won't fail, but we'll erroneously wake up the UMA reclaim thread. See r327485.