uk_slabsize, uk_ppera, uk_ipers, uk_pages

[Andriy Gapon]

On 30/09/2014 14:44, Gleb Smirnoff wrote:
>   Andriy,
> 
> On Tue, Sep 30, 2014 at 02:18:02PM +0300, Andriy Gapon wrote:
> 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.

This is not true for kegs with multi-page slabs.  Consider a zone with 8KB items
on a system 4KB pages. Its keg uses slabs with the size of two pages, uk_ppera
is 2.  There is only one item per slab, uk_ipers is 1. Let's say there are two
slabs allocated. Then uk_pages is 4.  So, uk_ipers * uk_pages would give 4, but
in reality there are only two items.  The correct calculation must be (uk_pages
/ uk_ppera) * uk_ipers.

If you have enough CPUs for a pcpu zone to use multi-page slabs / allocations,
then the above will also be applicable. Consider "64 pcpu" and 8 CPUs.  You have
uk_ppera = 2, uk_ipers = 128.  If there is only 1 "real" slab allocated that's 2
pages, so uk_pages * uk_ipers = 256, but in reality the correct number of
provided items is (uk_pages / uk_ppera) * uk_ipers = 128.

BTW, it's a pity that you omitted the code that demonstrated the problem from
the quote.

> 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.

We do have 1:1 mapping between allocations and "real" slabs.  The imaginary
"slabs" specific to pcpu zones do not affect how the keg code works.

We do need both uk_ppera and uk_ipers, of course, because one allows to convert
between a number of pages and a number of slabs and the other allows to convert
between a number of items and the number of slabs.

-- 
Andriy Gapon