From owner-freebsd-current@FreeBSD.ORG Tue Dec 28 18:38:51 2004 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 AE22D16A4CE; Tue, 28 Dec 2004 18:38:51 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C38543D1F; Tue, 28 Dec 2004 18:38:51 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBSIclq7026137; Tue, 28 Dec 2004 13:38:47 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBSIclS3026136; Tue, 28 Dec 2004 13:38:47 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 28 Dec 2004 13:38:47 -0500 From: Bosko Milekic To: Jeff Roberson Message-ID: <20041228183847.GA24514@technokratis.com> References: <20041112123343.GA12048@peter.osted.lan> <200412161521.44026.jhb@FreeBSD.org> <200412271705.31625.jhb@FreeBSD.org> <20041228043327.GA96744@technokratis.com> <20041228132209.G60504@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041228132209.G60504@mail.chesapeake.net> User-Agent: Mutt/1.4.2.1i cc: jeffr@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Freeze 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: Tue, 28 Dec 2004 18:38:51 -0000 On Tue, Dec 28, 2004 at 01:24:01PM -0500, Jeff Roberson wrote: > On Mon, 27 Dec 2004, Bosko Milekic wrote: > > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=159278+0+current/freebsd-current > > > > (and see previous in thread for context). > > > > Let's hope. > > It might be better for the slab zones to msleep there rather than flood > the system with allocation requests. Imagine if many threads were to hit > this code path, the slabzone would get a new slab for each calling thread, > when really we only want one more. They will not flood the system with allocation requests. They will merely block in the VM if they need to (if the allocation is M_WAITOK, otherwise they will return NULL shortly thereafter). This is because after that check, in uma_zalloc_internal(), we enter the loop which performs a slab_zalloc() call (which dips into VM). The dipping into VM will not occur repeatedly, but only once, as it is supposed to; the change merely gives it a chance to do so. The uk_recurse check was designed to protect from recursion occuring from the VM itself and so should not prevent multiple threads from dipping into the VM, even if it is for the same zone. This is perhaps an implementation flaw (but it is separate), that under a starvation situation you might have two or more separate threads ask the VM for pages (when in fact only one slab needs to be allocated to satisfy N requests), but this scenario is rare and is in my opinion not worth changing the implementation for (in that kind of long-term starvation, you're likely facing serious problems that UMA alone cannot address anyway). > It seems like this bug should have been caught sooner with asserts rather > than a hang somewhere. Can you investigate why this did not happen? I don't see why the bug would have been hit sooner. The likelihood of another allocation request coming in through uma_zalloc_internal() _exactly_ when another is allocating a slab header within the window where uk_recurse > 0 is small. -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org