Date: Thu, 10 Jan 2002 15:13:27 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Nate Williams <nate@yogotech.com> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <3C3E2017.D8F55078@mindspring.com> References: <Pine.SUN.3.91.1020110161827.1485C-100000@pcnet1.pcnet.com> <3C3E168B.B768CDC8@mindspring.com> <15422.7120.512072.974803@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > 1) It is the first occurance of floating point in the > > context; this is complicated. > > It's actually not complicated. It can be treated as a completely > separate context (in a separate thread, or whatever). I'm trying like a bandit to avoid the "speerate thread" treatment of this issue, to avoid the need to call into the kernel to maintain the correct context on a per thread basis. 8-(. > > 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. > > Daniel's example stated it wasn't in the same context, hence > the need to restore the old (prior) context that was saved. I gotta say: this works now, when we are talking about processes, and it only gets as complicated as everyone is trying to make it when people try to use multiple FP contexts in a single multithreaded process. Does anyone know if the IA64 fixes the #$!$@! delayed signalling of FPU exceptions? > > 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. > > But, Terry. The context is per-thread. You can't treat as a > per-process context, becuase there *are* multiple contexts > (threads) per process, and each of these context has (the potential) > to have separate FPU context. > > This is just the way it is, like it or not. > > Here's a *very* simple Java example. [ ... Java example elided ... ] > This java program runs under FreeBSD as a single process, but has two > different thread contexts that do FPU operations. It's tempting to force this example to use explicit context saves, based on the JVM's knowledge of the use of the "double" class... Let's take another example: let's do exactly the same thing in a linear Java program, and then run two instances of the program at the same time. This will undeniably work right now in FreeBSD, since the lazy binding of the contexts is OK. This lets us recast the question in terms of "what happens that lets this work on process context switches with lazy FPU binding, and why do we think this same approach can not be used with use space threads?". > > 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. > > This conflicts with what you are saying above, because each 'thread' is > a different context in the same process. It's arguable whether it's a different FPU context, and even if it has to be... why the same approach to lazy binding will not work for it. I would be very tempted to move the lazy save area into user space, and then use a pointer to a pointer for it, so that the dereference via the kernel only requires one copy in/out, and the user scheduler can point to who has the point on the user space context switch. Dan (and Julian) have already argued that the kernel needs to be able to find out, after an involuntary switch, which user space thread has the context (in particular, to know if they are in the user space scheduler at the time), right? I don't see that having a get/save FPU context point would be any worse. I'm really tempted to dual map memory between the kernel and user space for each process to use for things like this (and perhaps two pages of it, at that, to allow for things like "getpid", "getuid", "umask", etc., etc. to all be zero call overhead, with some being read-only and some being read/write from the user space process). -- 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?3C3E2017.D8F55078>