On Wed, Oct 15, 2008 at 01:07:46PM +0000, Martin Husemann wrote: > On Wed, Oct 15, 2008 at 06:52:38AM +0000, Bill Stouder-Studenmund wrote: > > > > Module Name: src > > Committed By: wrstuden > > Date: Wed Oct 15 06:52:38 UTC 2008 > > > > Added Files: > > src/sys/arch/m68k/include: saframe.h > > src/sys/compat/netbsd32: netbsd32_sa.c netbsd32_sa.h > > src/sys/rump/librump/rumpkern/opt: opt_sa.h > > src/sys/sys: sa.h satypes.h savar.h > > > > Log Message: > > Merge wrstuden-revivesa into HEAD. Catch some files that I forgot > > to revive on HEAD in previous commit. > > Some archs do not have cpu_setfunc() any more - what should it do in the > modern > world and what ifdef should guard it? Could we revive cpu_setfunc() for them? The current (and previous design) depend on being able to recycle threads. A thread's life cycle (other than the initial one) is: a) Thread is allocated and is put in the cache. We used to cpu_setfunc() to sa_switchcall(), now we set it to sa_neverrun(). b) The vp's blessed thread blocks, and this thread gets woken up. We cpu_setfunc() it to sa_switchcall(). c) This thread runs in sa_switchcall(), allocates a new thread if the cache is low, delivers an upcall, and returns to userland. We are the blessed lwp at this point. d) In userland, code runs. Eventually we either trap or enter a systemcall and in the processing of that, we block. There is another thread in the cache, and this is step (b) for it. We are now nolonger the blessed lwp. e) we eventually unblock from whatever we were doing and finish processing in the kernel f) In the process of userret(), we note that we triggered a BLOCKED upcall. So instead of returning to userland, we hang ourself off of the need-an-unblocked list on the vp and we take steps to help encourage the blessed lwp to notice us. We technically hang out at the mi_switch() call in sa_unblock_userret(). We only run in this context again iff the process exits. g) the blessed lwp returns to userland and notices we're in the need-an -unblocked list, and fires off an unblocked upcall for our user context. We then get put into the cache. Later on, if the blessed lwp blocks, we can get picked up at step (b). We could g/c the stack at (g) and always reallocate in (b) if needed. Should we do this? > The old code had a comment: /* Construct kernel frame to return to in > cpu_switch() */ > but I think this is different nowadays? Probably. To be honest, this is the edge of things I'm still learning about. I was hoping this part was still just working from before. I'm very solid on everything else, just not as much this. ;-) Take care, Bill
Attachment:
pgpCOoKMnjnR1.pgp
Description: PGP signature