From owner-freebsd-smp Tue Jan 15 11:40:35 2002 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 65FC937B405; Tue, 15 Jan 2002 11:40:32 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g0FJeNI63717; Tue, 15 Jan 2002 11:40:23 -0800 (PST) (envelope-from dillon) Date: Tue, 15 Jan 2002 11:40:23 -0800 (PST) From: Matthew Dillon Message-Id: <200201151940.g0FJeNI63717@apollo.backplane.com> To: Alfred Perlstein Cc: smp@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: making malloc(9) smp safe? References: <20020113050836.Q7984@elvis.mu.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :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