Date: Tue, 14 May 2002 09:39:28 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Jonathan Mini <mini@freebsd.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 11120 for review Message-ID: <Pine.BSF.4.21.0205140938140.39774-100000@InterJet.elischer.org> In-Reply-To: <20020513192851.N43682@stylus.haikugeek.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mini@freebsd.org> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0205140938140.39774-100000>