These show the total amount of memory used for UMA slabs, and the limit
on such memory.
Details
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 24679 Build 23448: arc lint + arc unit
Event Timeline
sys/vm/uma_core.c | ||
---|---|---|
3813 | Why do you need this atomic ? Esp. since sysctl handler would not use volatile qualification. |
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. |
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(). */ |
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. |
sys/vm/uma_core.c | ||
---|---|---|
3813 | As I noted, sysctl would not access it as volatile. |
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. |
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. |