From owner-p4-projects Tue May 14 9:53:20 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 33AD137B406; Tue, 14 May 2002 09:53:12 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 1692937B400; Tue, 14 May 2002 09:53:11 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020514164021.DUOJ29832.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 14 May 2002 16:40:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA39789; Tue, 14 May 2002 09:39:29 -0700 (PDT) Date: Tue, 14 May 2002 09:39:28 -0700 (PDT) From: Julian Elischer To: Jonathan Mini Cc: Perforce Change Reviews Subject: Re: PERFORCE change 11120 for review In-Reply-To: <20020513192851.N43682@stylus.haikugeek.com> 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 am on end of long piece of wet string in Hungary back in real world after 21st.. chat thenn.. in themean while, work to get diffs working and push peter/john for a commit.. Julian On Mon, 13 May 2002, Jonathan Mini wrote: > 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