From owner-freebsd-current  Sat Feb 23 16:37:41 2002
Delivered-To: freebsd-current@freebsd.org
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by hub.freebsd.org (Postfix) with ESMTP
	id DB65C37B402; Sat, 23 Feb 2002 16:37:39 -0800 (PST)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id A872EAE2D8; Sat, 23 Feb 2002 16:37:39 -0800 (PST)
Date: Sat, 23 Feb 2002 16:37:39 -0800
From: Alfred Perlstein <alfred@FreeBSD.ORG>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: 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.)
Message-ID: <20020224003739.GL80761@elvis.mu.org>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200202232243.g1NMhZP49110@apollo.backplane.com>
User-Agent: Mutt/1.3.27i
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

* Matthew Dillon <dillon@apollo.backplane.com> [020223 14:43] wrote:
>     This is approximately what I am thinking.  Note that this gives us the
>     flexibility to create a larger infrastructure around the bucket cache,
>     such as implement per-cpu caches and so on and so forth.  What I have
>     here is the minimal implementation.

I strongly object to this implementation right now, please do not
commit it.  I already explained to you how to make the problem
go away but instead you insist on some complex api that pins
memory down like the damn zone allocator.  It's not needed, so
please don't do it.

-Alfred

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