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