From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 16:19:50 2005 Return-Path: X-Original-To: current@freebsd.org 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 2C92816A420; Mon, 12 Dec 2005 16:19:50 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from mail.acc.umu.se (mail.acc.umu.se [130.239.18.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id B302B43D80; Mon, 12 Dec 2005 16:19:27 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id 958ED498E; Mon, 12 Dec 2005 17:19:23 +0100 (MET) Received: from [192.168.1.100] (53dbce07.umea.cust.skycom.se [83.219.206.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.acc.umu.se (Postfix) with ESMTP id C364D48C8; Mon, 12 Dec 2005 17:19:20 +0100 (MET) Message-ID: <439DA34D.7040407@acc.umu.se> Date: Mon, 12 Dec 2005 17:20:29 +0100 From: Johan Bucht User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at acc.umu.se Cc: current@freebsd.org Subject: Re: New libc malloc patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Dec 2005 16:19:50 -0000 Daniel Eischen wrote: >On Sun, 11 Dec 2005, Jason Evans wrote: > > >>>>As for supporting recursive spinlocks, I doubt that the overhead >>>>would be acceptable in general. If I could get rid of the need for >>>>the one recursive lock in malloc.c, I certainly would. =) >>>> >>>> >>>Why do we need a recursive mutex? Can you not restructure the >>>code so that it is not needed? >>> >>> >>There is an internal arena that the malloc code uses for allocating >>internal data structures. In some cases, the internal arena has to >>recursively allocate. If there were no object caching, it might be >>possible to pre-allocate, such that recursion never happens, but >>given the object caching, it's difficult to reason about precisely >>what will occur internally for a single malloc/free operation. There >>are some other possibilities, but nothing I've thought of so far is >>simple or elegant. >> >> > >Well, just lock around the external functions and remove all locking >from the internal and recursive functions. Can't all recursion >be replaced with loops anyways ;-) > > > Simple description of the issues following. First ideal case, no recursive locking needed: 1. Lock the local arena to allocate memory 2. If we need to allocate internal data structures lock the base arena 2.1. Allocate memory from the base arena 2.2. Unlock base arena 3. Unlock local arena The ideal case assumes that the base arena have everything it needs and don't have to set up internal data structures to handle the allocations. Actual case: 0. From malloc(3) friends get a local arena and pass that into the internal functions 1. Lock the supplied arena 2. If we need to allocate internal data structure goto step 1, using the base arena instead of one of the local arenas 2.1 Allocate memory from base arena 2.2 Unlock base arena 3. Unlock arena This means that we can lock the base arena recursivly, should the allocation of memory from the base arena need to allocate memory. Solving this would need some special handling for the base arena (avoid using the same interface as the other arenas or statically allocate the base arena). /Johan Bucht