From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 18 10:06:01 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AD2037B401 for ; Fri, 18 Jul 2003 10:06:01 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF21A43FBD for ; Fri, 18 Jul 2003 10:05:59 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h6IH5wv00989 for ; Fri, 18 Jul 2003 19:05:58 +0200 (MEST) Date: Fri, 18 Jul 2003 19:05:58 +0200 (CEST) From: Harti Brandt To: hackers@freebsd.org Message-ID: <20030718185122.N14232@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: SMP problem with uma_zalloc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2003 17:06:01 -0000 Hi all, it seems there is a problem with the zone allocator in SMP systems. I have a zone, that has an upper limit on items that resolves to an upper limit of pages of 1. It turns out, that allocations from this zone get stuck from time to time. It seems to me, that the following happens: - on the first call to uma_zalloc a page is allocated and all the free items are put into the cache of the CPU. uz_free of the zone is 0 and uz_cachefree holds all the free items. - when the next call to uma_zalloc occurs on the same CPU, everything is fine. uma_zalloc just gets the next item from the cache. - when the call happens on another CPU, the code finds uz_free to be 0 and checks the page limit (uma_core.c:1492). It finds the limit already reached and puts the process to sleep (uma_zalloc was called with M_WAITOK). - the process may sleep there forever (depending on circumstances). If M_WAITOK is not set, the code will falsely return NULL while there are still free items (albeight in the cache of another CPU). I wonder whether this is intended behaviour. If yes, this should be definitely documented. uma_zone_set_max() seems to be documented only in the header file and it does not mention, that free items may not actually be allocatable because they happen to sit in another CPU's cache. If it is not intended (I would prefer this), I wonder how one can get the items out of another's CPU cache. I'm not too familiar with this code. I suppose this should be done somewhere around uma_core.c:1485? Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org