Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

Davide Libenzi
2007-03-02T20:18:43Z

On Fri, 2 Mar 2007, Ingo Molnar wrote:

>
> * Davide Libenzi <davidel@xmailserver.org> wrote:
>
> > [...] We're still missing proper FPU context switch in the
> > move_user_context(). [...]
>
> yeah - i'm starting to be of the opinion that the FPU context should
> stay with the threadlet, exclusively. I.e. when calling a threadlet, the
> 'outer loop' (the event loop) should not leak FPU context into the
> threadlet and then expect it to be replicated from whatever random point
> the threadlet ended up sleeping at. It would be possible, but it just
> makes no sense. What makes most sense is to just keep the FPU context
> with the threadlet, and to let the 'new head' use an initial (unused)
> FPU context. And it's in fact the threadlet that will most likely have
> an acrive FPU context across a system call, not the outer loop. In other
> words: no special FPU support needed at all for threadlets (i.e. no
> flipping needed even) - this behavior just naturally happens in the
> current implementation. Hm?

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.
I think it should also follow the async thread (old, going-to-sleep,
thread), since a threadlet might have that dirtied, and as a consequence
it'll want to find it back when it's re-scheduled.
So, IMO, if the USEDFPU bit is set, we need to sync the dirty FPU context
with an early unlazy_fpu(), *and* copy the sync'd FPU context to the new head.
This should really be a fork of the dirty FPU context IMO, and should only
happen if the USEDFPU bit is set.

- Davide