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

Consider making the initial value of 0 explicit here.

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

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

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.

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.

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(). */

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.

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

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