From owner-freebsd-arch Wed Aug 28 18: 0:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 851F837B401; Wed, 28 Aug 2002 18:00:37 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77BBA43E42; Wed, 28 Aug 2002 18:00:36 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020829010035.HKJD13899.sccrmhc02.attbi.com@InterJet.elischer.org>; Thu, 29 Aug 2002 01:00:35 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA94770; Wed, 28 Aug 2002 17:43:22 -0700 (PDT) Date: Wed, 28 Aug 2002 17:43:20 -0700 (PDT) From: Julian Elischer To: Jon Mini Cc: arch@FreeBSD.ORG Subject: Re: Process/thread states. In-Reply-To: <20020828205908.GB3751@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 28 Aug 2002, Jon Mini wrote: > Julian Elischer [julian@elischer.org] wrote : > > > #define TD_ST_SUSPQ 0x01 /* uses runq field */ > > #define TD_ST_RUNQ 0x02 /* uses runq field */ > > #define TD_ST_RUNNING 0x03 /* uses no (virtual) field */ > > #define TD_ST_MTX 0x04 /* uses mtx field */ > > #define TD_ST_RQ_MASK 0x07 /* mask of non sleep states */ > > #define TD_ST_SLPQ 0x08 /* uses slpq field */ > + #define TD_ST_UNBOUND 0x10 /* not bound to a KSE */ > + #define TD_ST_UPCALL 0x20 /* scheduled for upcall */ > > enum thread_state { > > TDS_UNQUEUED = 0x00, > > TDS_SLP = TD_ST_SLPQ, > > TDS_RUNQ = TD_ST_RUNQ, > > TDS_RUNNING = TD_ST_RUNNING, > > TDS_SUSPENDED = TD_ST_SUSPQ, > > TDS_MTX = TD_ST_MTX, > > TDS_SUSP_SLP = TD_ST_SUSPQ|TD_ST_SLPQ, > > TDS_RUN_SLP = TD_ST_RUNNING|TD_ST_SLPQ, > > TDS_RUNQ_SLP = TD_ST_RUNQ|TD_ST_SLPQ, > > TDS_MTX_SLP = TD_ST_MTX|TD_ST_SLPQ, > > TDS_SWAPPING = TD_ST_SLPQ|TD_ST_RQ_MASK + 1, > > TDS_IWAIT, /* needed? */ > | TDS_SURPLUS = TDS_UNQUEUED|TD_ST_UNBOUND, > + TDS_UPCALLING = TD_ST_RUNQ|TD_ST_UPCALL > > }; > > This would make upcalls walk through the states like this: > - In the UMA slab, the thread is TDS_SURPLUS The value there is "undefined". The CTOR should give it a known value. > - allocated as kse->ke_tdspare, still TDS_SURPLUS TDS_UNQUEUED. > - thread_schedule_upcall() grabs it, and it becomes TDS_UPCALLING No I think it's TDS_RUNQ then.. with a qualifier in the flags of "Upcalling". Upcalling is not a scheduler (run/stop/sleep/runq) state in my opinion. It is a qualifier on how it where it will run but not how/when/if. > - thread_userret() sees it, it gets bound to a KSE, and becomes > TDS_RUNNING just like any other currently running thread. It MUST already be running by that time. Anything that is running must be in state RUNNING.. (please!) > > I hate to add another state, especially for one so fleeting, but the current > use of td_flags for this strikes me as a bit bogus. I think is is a flag to control it's flow of execution, and not a shceduling state... differnt thing. I think.. > > OTOH, "unused" (TDS_SURPLUS) is a totally valid state. I think that UNQUEUED could be it.. it means Not at all under the control of the scheduler or friends. What makes it even worse is that it looks like it MAY have to look like this: #define TD_ST_SUSPQ 0x01 /* uses runq field */ #define TD_ST_RUNQ 0x02 /* uses runq field */ #define TD_ST_RUNNING 0x03 /* uses no (virtual) field */ #define TD_ST_MTX 0x04 /* uses mtx field */ #define TD_ST_RQ_MASK 0x07 /* mask of non sleep states */ #define TD_ST_SLPQ 0x08 /* uses slpq field */ #define TD_ST_SWAPPPED 0x10 /* uses slpq field */ enum thread_state { TDS_UNQUEUED = 0x00, TDS_SLP = TD_ST_SLPQ, TDS_RUNQ = TD_ST_RUNQ, TDS_RUNNING = TD_ST_RUNNING, TDS_SUSPENDED = TD_ST_SUSPQ, TDS_MTX = TD_ST_MTX, TDS_SUSP_SLP = TD_ST_SUSPQ|TD_ST_SLPQ, TDS_RUN_SLP = TD_ST_RUNNING|TD_ST_SLPQ, TDS_RUNQ_SLP = TD_ST_RUNQ|TD_ST_SLPQ, TDS_MTX_SLP = TD_ST_MTX|TD_ST_SLPQ, TDS_SWAP_SLP = TD_ST_SWAPPED|TD_ST_SLPQ, TDS_SWAP_SUSP = TD_ST_SWAPPED|TD_ST_SUSPQ, TDS_SWAP_SUSP_SLP = TD_ST_SWAPPED|TD_ST_SLPQ|TD_ST_SUSPQ, }; This is because threads may be on their processes suspended queue AND on a sleep queue, (due to catching a SIGSTOP in msleep) AND be swapped out. It is important that the fact that they are on these two queues NOT BE LOST, in fact while the thread is swapped out (i.e. kernel stack and pcb are swapped out), a wakeup() event may occur, and it needs to be able to remove it from the sleep queue at that time. The SIGCONT couls also occur which means that the threads should be taken off the suspended queue as well. All while 'swapped out' the only thing that can't be done is to put it on the run queue or to run it while it's swapped out, (or probably be blocked on a mutex). Now, if a thread is unsuspended and woken up while swapped out, then when swapped in again how do we work out what to do with it? "if not asleep or blocked it must be runnable?" I guess that's what happens now,.. anyhow look at teh diagram I just posted to -arch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message