From owner-p4-projects Fri May 3 10:23:55 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id C581937B485; Fri, 3 May 2002 10:22:38 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id AA6BD37B47A; Fri, 3 May 2002 10:21:43 -0700 (PDT) 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 <20020503172040.EKPK4412.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 3 May 2002 17:20:40 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA83367; Fri, 3 May 2002 10:09:16 -0700 (PDT) Date: Fri, 3 May 2002 10:09:15 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: Perforce Change Reviews , Perforce Change Reviews , Jonathan Mini Subject: Re: PERFORCE change 10740 for review In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-p4-projects@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG to some extent I agree with you but realise that all tehuma stuff has occured since young Edith dorothy was born.. :-) (i.e the patches predate uma) On Fri, 3 May 2002, John Baldwin wrote: > > On 03-May-2002 John Baldwin wrote: > > > > On 03-May-2002 Julian Elischer wrote: > >> > >> > >> On Fri, 3 May 2002, John Baldwin wrote: > >> > >>> > >>> We already have a slab allocator for that, no need to reinvent it. > >> > >> You do NOT have a slab allocator that allocates fulli linked up thread > >> structures with preallocated vm ojects for the stack etc. > > > > Uh, only cause you haven't bothered to write proper constructor's > > destructor's > > for the uma zone then. We _do_ have a proper slab allocator and by trying > > to manage it yourself you are simply preventing uma from being fully able > > to manage the memory in the system. > > Correction. :) s/ctor/init/, s/dtor/fini/. In uma we have four functions > associated with a zone: > > ctor() - called whenever a 'user' malloc, like uma_zalloc() is called > dtor() - called whenever a 'user' free is called() > init() - called when on objects when they are actually allocated into > a slab from kmem > fini() - called when on objects when the slab they are part of is > released back to kmem > > Thus, you can perform type-stable initialization in init() and teardown > in fini() and it won't get called on each malloc() or free(), but only > when the memory is actually allocated from of free'd to KVM. > > By allowing uma to manage your "free" but still type-stable threads, > you allow it to release those unused structures to kvm if there is a > memory shortage. This lets the kernel adjust to temporary memory needs > on the fly. For example, if we suddenly need a lot of mbuf's, uma can > go find some unused slabs, fini() them, and then make them into mbuf > slabs instead. Later when the need for mbuf's recedes to its normal > level and more threads are needed, uma can grab some of the free mbuf > slabs and convert them to thread slabs. This allows the kernel to better > adjust to changing memory conditions in the kernel. If you insist on > using your own free list to duplicate the work of init()/fini(), you > reduce uma's ability to handle changing memory conditions. > > Does this make sense? > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message