From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 30 12:16:42 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 758A3166; Tue, 30 Sep 2014 12:16:42 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7EB25FF7; Tue, 30 Sep 2014 12:16:41 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA22062; Tue, 30 Sep 2014 15:16:40 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XYwMB-000GCH-N7; Tue, 30 Sep 2014 15:16:39 +0300 Message-ID: <542A9EF0.3050405@FreeBSD.org> Date: Tue, 30 Sep 2014 15:15:44 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: uk_slabsize, uk_ppera, uk_ipers, uk_pages References: <542A916A.2060703@FreeBSD.org> <20140930114424.GD73266@glebius.int.ru> In-Reply-To: <20140930114424.GD73266@glebius.int.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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 12:16:42 -0000 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. > > 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