Date: Wed, 6 Aug 2003 17:12:40 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: threads@freebsd.org Subject: Re: KSE/ia64: a quick update Message-ID: <Pine.GSO.4.10.10308061704520.18664-100000@pcnet5.pcnet.com> In-Reply-To: <20030806205308.GA1179@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Aug 2003, Marcel Moolenaar wrote: > On Wed, Aug 06, 2003 at 03:28:52PM -0400, Daniel Eischen wrote: > > > If you chose this route, or something similar that needs a > > system call, you might optimize the kernel. You might > > only need to make an upcall when the KSE's quantum expired > > instead of whenever a thread was interrupted. Or perhaps > > when there are no unblocked threads in the kernel that > > require an upcall to notify the UTS, there's no need > > to make an upcall. > > > > In regards to the high FPU thing. Can't you tell the > > UTS via the exported context whether a high FPU restore > > is necessary? > > It's always necessary. Even if the high FP wasn't enabled > at the time of the interrupt, it doesn't mean that the high > FP registers don't have valid values. It's just that they > haven't been accessed in that timeslice yet (we need some > heuristics to enable the high FP by default for that process > until after some timeout -- that avoids a trap every time > slice). I see. FWIW, we don't have a way to eliminate the trap on x86 either. Once the context is marked with the FPU registers being from the FPU itself or the PCB, we always restore them. The thing to realize I guess is that once you trap, you won't do it again until the FPU has been taken away again. So you may only trap the first time, and a few other times following that you may not. You can have to weigh that against always using a system call to restore the context. I'm not sure what the difference would be. > Also, another thread may use the high FP registers and since > user level threading is indistinguishable for the kernel, we > need to either have synchronous context switches or save the > whole lot for async context switches. > > I think I'll go with the following (for async contexts): > > o Use ifa and isr in the context to pass the pointer to the > mailbox and the value we want to write to it. Both are > only used by the kernel to pass information about the > fault or interrupt to the kernel, so they are unused > fields in contexts. > o Set a flag in the context to indicate that we want the > mailbox set (if applicable). > o Use the break-based syscall path to call setcontext(2). > o Have the kernel switch the context and set the mailbox. > > It's a bit of a hack, but I think other solutions are much > more painful. Both implementation-wise and kludge-wise. If there's anything more we can do, let us know. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10308061704520.18664-100000>