From owner-freebsd-current  Sat Feb 23 15:12:56 2002
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 17C2A37B416; Sat, 23 Feb 2002 15:12:37 -0800 (PST)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.11.6/8.9.1) id g1NNCaH54765;
	Sat, 23 Feb 2002 15:12:36 -0800 (PST)
	(envelope-from dillon)
Date: Sat, 23 Feb 2002 15:12:36 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200202232312.g1NNCaH54765@apollo.backplane.com>
To: Terry Lambert <tlambert2@mindspring.com>
Cc: Alfred Perlstein <alfred@FreeBSD.ORG>,
	Bosko Milekic <bmilekic@unixdaemons.com>,
	Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>,
	current@FreeBSD.ORG, John Baldwin <jhb@FreeBSD.ORG>
Subject: Re: malloc_bucket() idea (was Re: How to fix malloc.)
References: <200201051752.g05Hq3gG074525@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <XFMail.020114020307.jhb@FreeBSD.org> <200201241022.g0OAMISM093913@faber.r.dl.itc.u-tokyo.ac.jp> <20020124024534.V13686@elvis.mu.org> <200202131739.g1DHdZT5023794@rina.r.dl.itc.u-tokyo.ac.jp> <200202190945.g1J9j9kg076110@rina.r.dl.itc.u-tokyo.ac.jp> <200202232051.g1NKpE741310@apollo.backplane.com> <20020223211449.GJ80761@elvis.mu.org> <200202232243.g1NMhZP49110@apollo.backplane.com> <3C78200E.EC89C4E1@mindspring.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-current.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-current>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-current>
X-Loop: FreeBSD.ORG


:OTOH, A per CPU bucket list means no bucket mtx would be necessary;
:without that, it's just replacing one type of contention for another,
:I think, until you start making mutex selection indeterminate.  8^(.
:
:Really, this delayed freeing idea is starting to get uglier than
:just going to per CPU pools...
:
:-- Terry

    Well, if we want to rewrite malloc() a per-cpu pool inside a critical
    section would not be that difficult.  The 'bucket' array would
    simply be placed in the per-cpu area.  However, with malloc() we still
    have a serious problem with the malloc_type structure statistics.  There
    would have to be per-cpu information for those as well.

    critical_enter() isn't much better then a mutex.  It can
    be optimized to get rid of the inline cli & sti however.  Actually, it
    can be optimized trivially for i386, all we have to do is check the
    critical nesting count from the interrupt code and set the 
    interrupts-disabled bit in the returned (supervisor mode) frame.

    critical_enter() and critical_exit() would then be nearly perfect.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message