From owner-freebsd-arch Fri Mar 1 13:20:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id D955537B4A1 for ; Fri, 1 Mar 2002 13:20:13 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020301212013.OZPJ1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 1 Mar 2002 21:20:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA12950; Fri, 1 Mar 2002 13:15:31 -0800 (PST) Date: Fri, 1 Mar 2002 13:15:29 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Jeff Roberson , arch@FreeBSD.ORG Subject: Re: Slab allocator update In-Reply-To: <200203012036.g21KaIs46295@apollo.backplane.com> 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 Fri, 1 Mar 2002, Matthew Dillon wrote: > > :On Wed, 27 Feb 2002, Jeff Roberson wrote: > : > :> > :> 1) Fix the last lock order reversal. > :> 2) Fixup the statistics for uma and malloc. > :> 3) Convince people to test it. > :> 4) Commit. > : > :Please try integrate it in such a form that both new and old can be > :compiled in with a config option. > :(for a while) > : > :> 5) Work on converting everything to uma_* interfaces, and adding > :> initializers. > : > :Do lots of testingto prove that it's an improvement. > > I think it only needs to have 'similar' performance to be an > improvement, since the eventual goal is to collapse the > kernel malloc and zalloc subsytems into one. > > Right now we have rather serious issues with KVM exhaustion. The > fact that the existing kernel malloc uses kmem_map and zalloc uses > kernel_map for expansion, and that none of the memory is ever returned, > is one of the primary culprits. I would happy if that mess were > consolidated into one universal allocation mechanism capable of > returning memory to the system even if it meant a slight loss in > performance. > > I'm not sure I agree with an integration that tries to keep the > old mechanisms alive. If it's easy to do, then sure. But otherwise > we should just grin and bear it. it should be possible to make a MALLOC wrapper for uma "Universal memory allocator?" sounds a bit ambitious :-) > > -Matt > Matthew Dillon > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message