From owner-freebsd-arch Wed Nov 6 11:37: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22FDD37B406 for ; Wed, 6 Nov 2002 11:37:00 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id ADF8D43E88 for ; Wed, 6 Nov 2002 11:36:55 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 15328 invoked by uid 1000); 6 Nov 2002 19:36:55 -0000 Date: Wed, 6 Nov 2002 11:36:55 -0800 (PST) From: Nate Lawson To: Jeff Roberson Cc: Poul-Henning Kamp , arch@freebsd.org Subject: malloc(9) performance In-Reply-To: <20021106141427.J1374-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Nov 2002, Jeff Roberson wrote: > On Fri, 1 Nov 2002, Poul-Henning Kamp wrote: > > > phk 2002/11/01 10:58:13 PST > > > > Modified files: > > sys/sys malloc.h > > sys/kern kern_malloc.c > > Log: > > Introduce malloc_last_fail() which returns the number of seconds since > > malloc(9) failed last time. This is intended to help code adjust > > memory usage to the current circumstances. > > > > A typical use could be: > > if (malloc_last_fail() < 60) > > reduce_cache_by_one(); > > > > Revision Changes Path > > 1.113 +16 -0 src/sys/kern/kern_malloc.c > > 1.68 +1 -0 src/sys/sys/malloc.h > > > > I would like to add a 'flush' callback to uma. So each zone could get a > callback when the system is low on memory and it could reduce it's memory > footprint. This would be very effective for something like the vnode > cache or the directory cache, etc. > > What do you think of this? It would be trivial to add. > > Cheers, > Jeff Yes, I think this would be useful but also, if appropriate, portions of the kernel that traditionally used their own freelists should go back to just malloc/free if the new malloc is fast enough(*) for their use. Not trying to hijack the conversation so please keep it on track, but this brought up a question I never heard answered. The new malloc(9) is supposed to be quick enough(*) that drivers should stop using their own freelists. Does anyone have performance numbers on this? I want to check latency for small and big allocations. I am specifying my own malloc type so I assume malloc(9) will chain recently-used objects before coalescing. Followups to arch@ -Nate (*) For me, fast enough means sustaining 100000 small (400 byte) and big (64k) allocations/frees per second (one every 10 us). Maximum memory in use at any point in time would be a few MB. Latency is my main concern and memory fragmentation much less so. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message