Date: Thu, 10 Jan 2002 14:32:43 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Nate Williams <nate@yogotech.com>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <3C3E168B.B768CDC8@mindspring.com> References: <Pine.SUN.3.91.1020110161827.1485C-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > > Type slowly, I'm old, and other people on this list are older... > > > > What problem? > > > > If signal code doesn't touch the FPU statem then it's totally > > transparent to the lazy save of FPU context state. > > OK, so the signal handler saves the interrupted context > and resumes/starts another context. With me so far? Yes. > Perhaps a few contexts later, and perhaps even a few > signals later, Still with you... > and after doing some additional floating point stuff, Bzzt! OK, how does this "additional floating point stuff" happen? I see exactly two cases: 1) It is the first occurance of floating point in the context; this is complicated. 2) It is an occurance subsequent to the first in the context, in which case, when the context was brought back, the state was brought back, as well, so it's already dealt with, since the previous context could have been lazy-save at that point. My answer to #1 is to treat the FP context as being "per process", rather than "per thread", and then do explicit (non-lazy) saves _only_ when migrating between CPUs. > the originally interrupted context is resumed. If the > FPU state as it existed when it was interrupted is not > in the context, then the FPU state will not be correctly > restored. > > The FPU state as it exists when the context is restored > is not necessarily the FPU state as when the context > was interrupted. Uh, signals are not interrupts. The %msw examination can be used for kernel faults/traps/etc. that result in a context switch. I thought the reason we had seperate weird calls for the signal longjump/setjmp stuff was to handle the FPU crap? > > So if I use the FPU, get context switched out, get sent a > > signal, as long as any FPU state gets set back before I > > trampoline out, everything's good, right? > > No, see above. You are not required to trampoline out of > the signal handler. It is perfectly valid to use siglongjmp > or setcontext to leave a signal handler (and the context > that you return to does not have to be the interrupted > context). In that case, setcontext must be a system call, the %msw must trap (and handle it that way, by having a %msw examination in the user space scheduler, using notification by the kernel if the FPU use used -- I like the "disable the FPU, and take a fault to enable it" suggestion someone else made -- probably by a copyout into a user context based on the FPU access fault being taken), or we should just bend over and assume all code uses the FPU, even though we know for a fact almost no code actually does. > > The lazy-bound > > FPU state, which is per-process is exactly where the > > process had it when it was switched out. So even if I'm > > time sliced out because some idiot wrote a lot of code in > > a signal handler because they didn't understand persistant > > conditions vs. events, when I'm switched back to the code > > in the signal handler, my FPU state is where it should be, > > right? > > I think I answered this, right? I'm not sure. It depends on whether the second use of the FPU in your example results in state being saved, or not. If you had a flag that said the process used the FPU (using a fault on first FPU access to get it is a good idea, IMO), then you could, conditionally on the flag, force an FPU fault as part of the context switch process to force the synchornization (if any), and/or just do explicit saves only in that case (i.e. if the flag is set). The only complication there is if the first access is in an odd context, like a signal handler, in which case, the thing being restored would not have been saved, already. It's tempting to say that the FPU enable/disable (and therefore the save/restore) should be a system call, and handled on a per thread basis by the user space scheduler. If the FPU is used, then you pay an extra system call per context switch penalty in the user space scheduler for the use of it. -- Terry 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?3C3E168B.B768CDC8>