Date: Wed, 6 Nov 2002 11:36:55 -0800 (PST) From: Nate Lawson <nate@root.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Poul-Henning Kamp <phk@FreeBSD.org>, arch@freebsd.org Subject: malloc(9) performance Message-ID: <Pine.BSF.4.21.0211061120360.15163-100000@root.org> In-Reply-To: <20021106141427.J1374-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0211061120360.15163-100000>