From owner-p4-projects Mon May 13 19:28:15 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id D9BA837B407; Mon, 13 May 2002 19:28:04 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from 12-234-96-171.client.attbi.com (12-234-96-171.client.attbi.com [12.234.96.171]) by hub.freebsd.org (Postfix) with ESMTP id C60E337B401 for ; Mon, 13 May 2002 19:28:03 -0700 (PDT) Received: by 12-234-96-171.client.attbi.com (Postfix, from userid 1000) id 67ACBA900; Mon, 13 May 2002 19:28:51 -0700 (PDT) Date: Mon, 13 May 2002 19:28:51 -0700 From: Jonathan Mini To: Julian Elischer Cc: Perforce Change Reviews Subject: Re: PERFORCE change 11120 for review Message-ID: <20020513192851.N43682@stylus.haikugeek.com> References: <200205101530.g4AFUn510685@freefall.freebsd.org> <3CDC2BB5.366A7BF0@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CDC2BB5.366A7BF0@elischer.org>; from julian@elischer.org on Fri, May 10, 2002 at 01:21:09PM -0700 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 Julian Elischer [julian@elischer.org] wrote : > Jonathan Mini wrote: > > > - When abandoning a thread (in thread_exit()), push the > > thread into its KSE's spare thread slot, and free the > > thread that is already there (if any). > > I assume there will only be a spare thread at other times in KSE type processes. Yes, except in the exit scenario for a normal process. In this case, we have this: - exit1() -> exit_thread() - exit_thread() pushes current thread to "spare" slot, and mi_throw()'s. - wait1() gets called later, and frees the thread in the spare slot as it cleans up the process. > > - When performing an upcall, pull the spare thread (if > > available) before allocating a new thread from uma. This > > is especially useful in msleep(), where not blocking again > > is highly preferable. > > - When pulling the KSE spare thread, allocate a new spare > > thread for the KSE before returning to userland for the > > upcall. > > I presume only for KSE mode processes. > i.e. for KSE mode processes there is always a spare thread available > unless we have just used it and have not yet returned to userland. > I can see some holes may need patching but should work.. That is exactly what we're doing here. The problem lies in that its theoretically possible for a KSE to schedule an upcall, but another (higher priority) process runs on that CPU that needs to schedule an upcall via the same KSE as well, and must allocate a thread from UMA, which could block. John and I talked about this, and he feels that in that case (which is an edge case to begin with), it'll be ok to block because the system will be really starved anyways. > [ ... lots of nits ... ] I'll look over and respond to the nits later. -- Jonathan Mini http://www.haikugeek.com "He who is not aware of his ignorance will be only misled by his knowledge." -- Richard Whatley To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message