Date: Sat, 23 Feb 2002 14:10:36 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <alfred@FreeBSD.ORG>, Bosko Milekic <bmilekic@technokratis.com> Cc: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, current@FreeBSD.ORG, John Baldwin <jhb@FreeBSD.ORG> Subject: Re: How to fix malloc. Message-ID: <200202232210.g1NMAaB41797@apollo.backplane.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
:All these per-subsystem free-lists are making me nervous in both
:complexity and wasted code...
:
:Ok, instead of keeping all these per-subsystem free-lists here's what
:we do:
:
:In kern_malloc:free() right at the point of
: if (size > MAXALLOCSAVE) we check if we have Giant or not.
: if we do not then we simply queue the memory
: however, if we do then we call into kmem_free with all the queued memory.
:
:This ought to solve the issue without making us keep all these
:per-cpu caches.
Hmm. I don't like generalizing it to that extent. What if we simply
assert that Giant is held if size > MAXALLOCSAVE in free()? i.e. for
the moment we require that any 'large allocations' use Giant. Then
we can freely use free() to free smaller allocations without Giant.
There are three other problems: (1) malloc() itself will call kmem_malloc()
even if M_NOWAIT is passed, so we can't optimize malloc()-without-giant
unless we add a new flag to deal with this situation.
And, (2) we have a single mutex, malloc_mtx. This is Bosko's code so
I am adding him to the To: list. Bosko, it looks like with a simple
cleanup to the msleep() call we can use a pool lock instead of malloc_mtx,
which would give us the ability to lock malloc() on a bucket-by-bucket
basis. The addition of a another malloc flag will allow us to tell
malloc() to return NULL if it can't do the operation with its own mutex.
And, (3) we wind up getting and releasing two mutexes instead of one
in the code I was originally refering to, because setsid() already gets
an SX lock and I was just going to fold the free list into that. Still,
I don't mind doing it via malloc().
What do people think?
-Matt
Matthew Dillon
<dillon@backplane.com>
:By the way, since "MAXALLOCSAVE" is some multiple of PAGE_SIZE, we
:really don't have to worry about it when freeing small structures
:although that puts evilness into malloc(9) consumers.
:
:Can you please consider that instead of continueing down this path
:of per-subsystem caches?
:
:thanks,
:--
:-Alfred Perlstein [alfred@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?200202232210.g1NMAaB41797>