Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Feb 2002 02:40:11 -0500
From:      Bosko Milekic <bmilekic@unixdaemons.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, 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:  <20020224024011.A35319@unixdaemons.com>
In-Reply-To: <200202232312.g1NNCaH54765@apollo.backplane.com>; from dillon@apollo.backplane.com on Sat, Feb 23, 2002 at 03:12:36PM -0800
References:  <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> <200202232312.g1NNCaH54765@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sat, Feb 23, 2002 at 03:12:36PM -0800, Matthew Dillon wrote:
> 
> :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.

  Someone (jeffr) is already working on a new allocator to hopefully
[at least] eventually replace malloc(9) and various other kernel
allocators. It will support per CPU working-sets and some cache friendly
goodies.

-- 
Bosko Milekic
bmilekic@unixdaemons.com
bmilekic@FreeBSD.org


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020224024011.A35319>