On 3/2/07, Davide Libenzi <davidel@xmailserver.org> wrote:
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.
And if you actually think this through, I think you will arrive at (a subset of) the conclusions I did a week ago: to keep the threadlets lightweight enough to schedule and migrate cheaply, they can't be allowed to "own" their own FPU and TLS context. They have to be allowed to _use_ the FPU (or they're useless) and to _use_ TLS (or they can't use any glibc wrapper around a syscall, since they practically all set the thread-local errno). But they have to "quiesce" the FPU and stash any thread-local state they want to keep on their stack before entering the next syscall, or else it'll get clobbered. Keep thinking, especially about FPU flags, and you'll see why threadlets spawned from the _same_ threadlet entrypoint should all run in the same pool of threads, one per CPU, while threadlets from _different_ entrypoints should never run in the same thread (FPU/TLS context). You'll see why threadlets in the same pool shouldn't be permitted to preempt one another except at syscalls that block, and the cost of preempting the real thread associated with one threadlet pool with another real thread associated with a different threadlet pool is the same as any other thread switch. At which point, threadlet pools are themselves first-class objects (to use the snake oil phrase), and might as well be enhanced to a data structure that has efficient operations for reprioritization, bulk cancellation, and all that jazz. Did I mention that there is actually quite a bit of prior art in this area, which makes a much better guide to the design of round wheels than micro-benchmarks do? Cheers, - Michael - 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/
