Date: Tue, 15 Jan 2002 11:40:23 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@mu.org> Cc: smp@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: making malloc(9) smp safe? Message-ID: <200201151940.g0FJeNI63717@apollo.backplane.com> References: <20020113050836.Q7984@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Malloc has its own mutex, however when it needs to do page allocations
:via kmem_malloc() it drops the mutex and calls it.
:
:kmem_malloc() needs giant.
:
:what do I do?
:
:Do I grab giant before calling malloc(9)?
:Do I make malloc(9) aquire or recurse on giant automatically?
: (basically grab giant around kmem_malloc() call in malloc(9))
:
:?
:
:--
:-Alfred Perlstein [alfred@freebsd.org]
If you are trying to make malloc() SMP safe, then Giant cannot be
required to be held by the caller of malloc().
This implies that malloc() needs to grab Giant() when calling
kmem_malloc(), and kmem_malloc() should have an assertion that
Giant is being held.
This seems to me to dovetail quite nicely into the intent of
unwinding Giant, because the next step will be to make kmem_malloc()
SMP safe, which will mean being able to call *it* without Giant and
have it aquire Giant internally when necessary. This will also lead
to some nice potential optimizations within kmem_malloc() -- for
example, using a critical section to implement a per-cpu free-page
cache within kmem_malloc(). That (huff puff) would then mean that
the entire path will not need Giant except for the case where the
per-cpu free page cache is empty. kmem_malloc() would then aquire
Giant to re-fill the per-cpu cache and deal with the request.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201151940.g0FJeNI63717>