uk_slabsize, uk_ppera, uk_ipers, uk_pages

Gleb Smirnoff glebius at FreeBSD.org
Tue Sep 30 11:44:28 UTC 2014


  Andriy,

On Tue, Sep 30, 2014 at 02:18:02PM +0300, Andriy Gapon wrote:
A> I have a hard time understanding how to use uk_slabsize, uk_ppera, uk_ipers,
A> uk_pages to derive other useful characteristics of UMA kegs.  This is despite
A> the good descriptions of the fields and multiple examples of their usage in the
A> code.  Unfortunately, I find those examples to be at least inconsistent and
A> possibly contradictory.
A> 
A> First problem is quite obvious.  uk_slabsize has a too narrow type.  For
A> example, ZFS creates many zones with item sizes larger than 64KB.  So,
A> obviously, uk_slabsize overflows.  Not sure how that affects further
A> calculation, if any, but probably not in a good way.
A> On the other hand, there is probably no harm at all, because as far as I can see
A> uk_slabsize is actually used only within keg_small_init().  It is set but not
A> used in keg_large_init() and keg_cachespread_init().  It does not seem to be
A> used after initialization.  So, maybe this field could be just converted to a
A> local variable in keg_small_init() ?

Nice observation. I bet, that when I developed UMA_ZONE_PCPU this field was used
outside of keg_small_init(). It looks like now, uk_ipers and uk_pages are enough
to know outside of keg_small_init().

A> Now a second problem.  Even the names uk_ppera (pages per allocation) and
A> uk_ipers (items per slab) leave some room for ambiguity.  What is a relation
A> between the allocation and the slab?  It seems that some code assumes that the
A> slab takes the whole allocation (that is, one slab per allocation), other code
A> places multiple slabs into a single allocation, while other code looks
A> inconsistent in this respect.
<skip>
A> My personal opinion is that we should settle on the rule that the slab and the
A> allocation map 1:1 and fix the code that does not conform to that.
A> It seems that this is how the code that allocates and frees slabs actually
A> works.  I do not see any good reason to support multiple slabs per an allocation.

In case of UMA_ZONE_PCPU, the slab is ncpu times smaller than the allocation.

BUT, whenever you do uma_zalloc() you allocate not a single item, but ncpu items
at a time. That's why all statistics that you quoted work correctly. And that's
why we do not have 1:1 mapping of slab and allocation and we need to have uk_ppera,
and uk_ipers.

A> P.S.
A> By the way, we have some wonderful things in UMA code that are not used anymore
A> (if ever?) and are scarcely documented.  Perhaps some of those could be removed
A> to simplify the code:
A> - UMA_ZONE_CACHESPREAD
A> - uma_zsecond_add()
A> More generally it looks like the support for multiple zones using the same keg
A> is quite useful.  On the other hand the support for a zone using multiple kegs
A> is of questionable utility and at present that capability is not used.

I second on that.

-- 
Totus tuus, Glebius.


More information about the freebsd-hackers mailing list