Date: Tue, 30 Sep 2014 15:15:44 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: uk_slabsize, uk_ppera, uk_ipers, uk_pages Message-ID: <542A9EF0.3050405@FreeBSD.org> In-Reply-To: <20140930114424.GD73266@glebius.int.ru> References: <542A916A.2060703@FreeBSD.org> <20140930114424.GD73266@glebius.int.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?542A9EF0.3050405>