Page MenuHomeFreeBSD

Export some UMA info via sysctl.
ClosedPublic

Authored by markj on Jun 4 2019, 3:31 PM.

Details

Summary

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

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 24679
Build 23448: arc lint + arc unit

Event Timeline

markj created this revision.Jun 4 2019, 3:31 PM
dougm added inline comments.Jun 4 2019, 3:46 PM
sys/vm/uma_core.c
148

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

151

Consider making the initial value of 0 explicit here.

kib added inline comments.Jun 4 2019, 3:57 PM
sys/vm/uma_core.c
3813

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

markj added inline comments.Jun 4 2019, 4:05 PM
sys/vm/uma_core.c
148

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

151

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

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 added inline comments.Jun 4 2019, 4:14 PM
sys/vm/uma_core.c
148

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 added inline comments.Jun 4 2019, 4:23 PM
sys/vm/uma_core.c
148

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 accepted this revision.Jun 4 2019, 4:59 PM
kib added inline comments.
sys/vm/uma_core.c
3813

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

This revision is now accepted and ready to land.Jun 4 2019, 4:59 PM
markj added inline comments.Jun 4 2019, 5:02 PM
sys/vm/uma_core.c
3813

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

markj updated this revision to Diff 58243.Jun 4 2019, 7:35 PM

Add a comment for uma_kmem_limit.

This revision now requires review to proceed.Jun 4 2019, 7:35 PM
markj marked an inline comment as done.Jun 4 2019, 7:37 PM
markj added inline comments.
sys/vm/uma_core.c
148

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

dougm accepted this revision.Jun 4 2019, 7:37 PM
This revision is now accepted and ready to land.Jun 4 2019, 7:37 PM
alc accepted this revision.Jun 4 2019, 8:00 PM
This revision was automatically updated to reflect the committed changes.