On Fri, 2007-03-02 at 12:53 -0800, Davide Libenzi wrote:
> On Fri, 2 Mar 2007, Ingo Molnar wrote:
>
> >
> > * Davide Libenzi <davidel@xmailserver.org> wrote:
> >
> > > I think that the "dirty" FPU context must, at least, follow the new
> > > head. That's what the userspace sees, and you don't want an async_exec
> > > to re-emerge with a different FPU context.
> >
> > well. I think there's some confusion about terminology, so please let me
> > describe everything in detail. This is how execution goes:
> >
> > outer loop() {
> > call_threadlet();
> > }
> >
> > this all runs in the 'head' context. call_threadlet() always switches to
> > the 'threadlet stack'. The 'outer context' runs in the 'head stack'. If,
> > while executing the threadlet function, we block, then the
> > threadlet-thread gets to keep the task (the threadlet stack and also the
> > FPU), and blocks - and we pick a 'new head' from the thread pool and
> > continue executing in that context - right after the call_threadlet()
> > function, in the 'old' head's stack. I.e. it's as if we returned
> > immediately from call_threadlet(), with a return code that signals that
> > the 'threadlet went async'.
> >
> > now, the FPU state that was when the threadlet blocked is totally
> > meaningless to the 'new head' - that FPU state is from the middle of the
> > threadlet execution.
>
> For threadlets, it might be. Now think about a task wanting to dispatch N
> parallel AIO requests as N independent syslets.
> Think about this task having USEDFPU set, so the FPU context is dirty.
> When it returns from async_exec, with one of the requests being become
> sleepy, it needs to have the same FPU context it had when it entered,
> otherwise it won't prolly be happy.
> For the same reason a schedule() must preserve/sync the "prev" FPU
> context, to be reloaded at the next FPU fault.
The point Ingo was making is that the x86 ABI already requires the FPU
context to be saved before *all* function calls.
Unfortunately, this isn't true of other ABIs -- looking over the psABIs
specs I have laying around, AMD64, PPC64, and MIPS require at least part
of the FPU state to be preserved across function calls, and I'm sure
this is also true of others.
Then there's the other nasty details of new thread creation --
thankfully, the contents of the TLS isn't inherited from the parent
thread, but it still needs to be initialized; not to mention all the
other details involved in pthread creation and destruction.
I don't see any way around the pthread issues other than making a libc
upcall on return from the first system call that blocked.
--
Nicholas Miell <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
