Date: Sat, 19 Jan 2002 09:49:48 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Bruce Evans <bde@zeta.org.au> Cc: arch@FreeBSD.ORG Subject: Re: doreti() and userret() Message-ID: <Pine.BSF.4.21.0201190933540.2065-100000@InterJet.elischer.org> In-Reply-To: <20020120034844.A5320-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
My interest in this is because of KSEs. I have added code to doreti (assuming it was the last place I could add C code (due to the name) and now I find that it's not quite so simple.. (I never really looked ast ASTs much before) WHat I do before returning to userland is: 1/ (Only in KSE processes) check if there are other threads also wanting to return. If so, the current thread, having saved it's state to userland already, just exits, (thrtead_exic() calls cpu_throw(). If we are the last returning thread, we have also already written our frame out to userland, and we instead, do an UPCALL to the userland scheduler. 2/ check if we should be STOPPED or Single threadding (a variant of STOPPED where a particular thread is immune). If so, then the thread can not return to userland and in put in a per-process "suspended" queue, and mi_switch() is called. Some of this code is also done in non KSE processes. I'm now trying to work out where the real correct place to put these code segments is. On Sun, 20 Jan 2002, Bruce Evans wrote: > On Sat, 19 Jan 2002, Julian Elischer wrote: > > > Userret() is supposed to be called the last thing before the > > processor is returned to userland.. > > At least on i386's, this is only true for the pessimized returns from > syscall() and trap(). Returns from interrupt handlers normally just > return. They sometimes (rarely) go through ast() to handle cases where > userret() would do something. In my version of FreeBSD, userret() is > almost a no-op and almost all the things that were in userret() are in > ast(). So, Bruce, can you outline to use what is in BDEBSD that we can expect to see in the future? It soulds to em like it would be nice to get some more of your work in.. > > > As such it is called from syscall() and from fork_return(). > > However AFTER they call it doreti() is called, which in turn > > calls ast which sometimes calls userret() again..... > > I can't help but feel that there could be some retionalisation there.. > > There may be any number of calls to userret() for a single return to > userland, to handle events that arrive while previous calls are being > processed. Unnecessary calls are just pessimizations. In -current > there is one call in syscall(), etc. and a loop in ast() that may make > any number of calls. The loop must check for new events atomically > with exiting. The complications for this are best handled in ast(). Maybe there needs to be a single place for "really last" things. > > > Also, either userret() is the last thing to be called or > > ast() is, or maybe doreti is, but > > certainly they can't ALL be the last thing called before the kernel returns > > to user mode. > > The logical order is (doreti, ast, userret, iret). So you would remove userret from syscall() and fork_return()? How abou from ast()? > > > Is it possible that we could take the userret() out of > > syscall() and fork_return() > > and just make sure that it is always called from doreti()? > > I haven't completely taken it out. I do the pri_level setting inline and > call userret() only to handle the PS_PROFIL case. I think -current > only needs it for precisely these things too. I have quite a bit more to do in a threaded process. > > Bruce > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" 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.0201190933540.2065-100000>