From owner-p4-projects Fri May 3 9:40:58 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 5A83F37B421; Fri, 3 May 2002 09:40:20 -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 A202437B423; Fri, 3 May 2002 09:40:13 -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 <20020503164012.CSPM4412.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 3 May 2002 16:40:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA83159; Fri, 3 May 2002 09:32:09 -0700 (PDT) Date: Fri, 3 May 2002 09:32:09 -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 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. 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". > > >> - uma_zalloc(,M_WAITOK) will never return NULL, so don't bother > >> testing for it. > > > > You may be right, but I wasn't convinced that M_WAITOK was always > > correct. I was trying to concieve af a case where you may not ba able to > > wait when trying ot allocate a new thread.. > > for example if you are trying to allocate it when you are already in > > msleep().. it may be bad to sleep when in msleep already... > > I think I may have other ways to stop this but think about it and > > check the anti-recursion code in msleep(). > > It may be that M_NOWAIT is the right answer.. > > 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. > > -- > > 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