From owner-p4-projects Fri May 3 9:54:52 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 76B5237B421; Fri, 3 May 2002 09:54:18 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by hub.freebsd.org (Postfix) with ESMTP id 53C3437B41F for ; Fri, 3 May 2002 09:54:15 -0700 (PDT) Received: (qmail 11674 invoked from network); 3 May 2002 16:54:14 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 3 May 2002 16:54:14 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g43GsDF12177; Fri, 3 May 2002 12:54:13 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 03 May 2002 12:54:05 -0400 (EDT) From: John Baldwin To: Julian Elischer Subject: Re: PERFORCE change 10740 for review Cc: Jonathan Mini Cc: Jonathan Mini , Perforce Change Reviews 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 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. > getting a thread structure, adding the stack and then ripping it off again > when deallocatingnit is too heavy weight for what I want. You COULD > just leave teh stack attached, and trust the slab allocator (as we do to > not try free it back to the system, taking its stack with it, but i'd > rather spend the extra 100 bytes making sure that I KNOW what I have on > hand.. what we do now is (to quote peter) a "HACK". You don't need to deallocate the stack unless you are doing an actual destruct of the thread. This isn't hard. >> This in fork1(). I think a better way of avoiding this is to have each >> KSE have a spare thread it can use when a thread blocks. The first >> action a spare thread when it starts up is to allocate a new spare thread >> if needed. However, I think you should only have one spare thread per-KSE >> and not a list. > > I have a list of them but it can be small. Your list needs to make sure it always has one so that we don't have to do malloc's during msleep, etc. Also, I think holding more than one per KSE prevents uma from managing system memory as fully as it can. We have subsystems, please use them instead of trying to home-roll your own. -- 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