From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 30 11:44:27 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAB6841E; Tue, 30 Sep 2014 11:44:27 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47E2FC9E; Tue, 30 Sep 2014 11:44:26 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s8UBiOOe074177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Sep 2014 15:44:24 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s8UBiOfH074176; Tue, 30 Sep 2014 15:44:24 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 30 Sep 2014 15:44:24 +0400 From: Gleb Smirnoff To: Andriy Gapon Subject: Re: uk_slabsize, uk_ppera, uk_ipers, uk_pages Message-ID: <20140930114424.GD73266@glebius.int.ru> References: <542A916A.2060703@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542A916A.2060703@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 11:44:28 -0000 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. 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.