From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 07:00:17 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23E0F37B401; Mon, 21 Jul 2003 07:00:17 -0700 (PDT) Received: from godel.mtl.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6381C43F85; Mon, 21 Jul 2003 07:00:16 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: from godel.mtl.distributel.net (localhost [127.0.0.1]) h6LA4MEH045829; Mon, 21 Jul 2003 10:04:22 GMT (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by godel.mtl.distributel.net (8.12.9/8.12.9/Submit) id h6LA4MRK045828; Mon, 21 Jul 2003 10:04:22 GMT X-Authentication-Warning: godel.mtl.distributel.net: bmilekic set sender to bmilekic@technokratis.com using -f Date: Mon, 21 Jul 2003 10:04:22 +0000 From: Bosko Milekic To: harti@freebsd.org Message-ID: <20030721100422.GA45773@technokratis.com> References: <20030718185122.N14232@beagle.fokus.fraunhofer.de> <20030718132503.GB29449@technokratis.com> <3F198E7E.4040309@fokus.fhg.de> <20030719170355.GA37444@technokratis.com> <20030721085426.A48033@beagle.fokus.fraunhofer.de> <20030721092327.GA45509@technokratis.com> <20030721153144.Q83041@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030721153144.Q83041@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: SMP problem with uma_zalloc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2003 14:00:17 -0000 On Mon, Jul 21, 2003 at 03:47:54PM +0200, Harti Brandt wrote: > On Mon, 21 Jul 2003, Bosko Milekic wrote: [...] > BM> It sounds to me like your example is really not the general-case one. > BM> Basically, you're using a zone capped off at 1 page. Currently in > BM> UMA, this is the size of the slab. So, basically, you have this whole > BM> zone (with all associated overhead) so as to serve a maximum of only > BM> one slab. This defeats most of the assumptions made when the zone is > BM> created with PCPU caches. The zone maximum exists to prevent more > BM> than the specified amount of resources to be allocated toward the > BM> given zone; I don't think that the intention was "to ensure that if > BM> the maximum items aren't allocated, there will always be one > BM> available," despite the fact that that is the effective behavior on > BM> UP. > BM> > BM> The solution to your really small zone problem is to either make the > BM> zone bigger, or to hack at UMA to export the UMA_ZONE_INTERNAL API > BM> properly so that you can skip the pcpu caches for all allocations and > BM> go straight to the zone. I'd suggest that you make the zone bigger, > BM> unless there's a Really Good reason not to. > > I think I take two paths: for stuffs like VCC where there may be a large > number I will just remove the limit. The limits were a leftover when the > ATM code had its own memory pool code. For stuff where there is a high > probability that only a handful (usually 1 or 2) of them will be allocated > (network interfaces) I will try to make it to use malloc(). Ahhhh. Given the explanation, the small size of the limits makes a lot more sense now. Previously, the limit probably enforced the actual number of cached (pre-allocated) items in the pool. So, it was more than just a "limit," it was a cache size parameter. That is probably why its size was kept relatively small. In the zone setting, the limit can easily be made larger or removed altogether (if there is no danger of that structure consuming all of kernel memory). > How do you think about adding a paragraph for uma_zone_set_max to the man > page?: > > An upper limit of items in the zone can be specified with a call to > uma_zone_set_max. This limits the total number of items which includes: > allocated items, free items and free items in the per-cpu caches. On > systems with more than one CPU it may not be possible to allocate the > specified number of items, because all of the remaining free items may > be in the caches of the other CPUs when the limit is hit. Given that it has obviously led to confusion, this sort of change to the man page would be encouraging. Perhaps you would also ammend to it the purpose of uma_zone_set_max(), as it currently stands: "The purpose of uma_zone_set_max() is to limit the maximum amount of memory that the system can dedicate toward the zone specified by the 'zone' argument." Would you like to commit the change? > Regards, > harti > > -- > harti brandt, > http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private > brandt@fokus.fraunhofer.de, harti@freebsd.org Cheers, -- Bosko Milekic * bmilekic@technokratis.com * bmilekic@FreeBSD.org TECHNOkRATIS Consulting Services * http://www.technokratis.com/