On Wed, 14 Feb 2007, Benjamin LaHaise wrote: > On Wed, Feb 14, 2007 at 12:14:29PM -0800, Davide Libenzi wrote: > > I think you may have mis-interpreted my words. *When* a schedule would > > block a synco execution try, then you do have a context switch. Noone > > argue that, and the code is clear. The sys_async_exec thread will block, > > and a newly woke up thread will re-emerge to sys_async_exec with a NULL > > returned to userspace. But in a "cachehit" case (no schedule happens > > during the syscall/*let execution), there is no context switch at all. > > That is the whole point of the optimization. > > And I will repeat myself: that cannot be done. Tell me how the following > what if scenario works: you're in an MMX optimized memory copy and you take > a page fault. How does returning to the submittor of the async operation > get the correct MMX state restored? It doesn't.
Bear with me Ben, and let's follow this up :) If you are in the middle of an MMX copy operation, inside the syscall, you are: - Userspace, on task A, calls sys_async_exec - Userspace in _not_ doing any MMX stuff before the call - We execute the syscall - Task A, executing the syscall and inside an MMX copy operation, gets a page fault - We get a schedule - Task A MMX state will *follow* task A, that will be put to sleep - We wake task B that will return to userspace So if the MMX work happens inside the syscall execution, we're fine because its context will follow the same task being put into sleep. Problem would be to preserve the *caller* (userspace) context. But than can be done in a lazy way (detecting if task A user the FPU) like we're currently doing it, once we detect a schedule-out condition. That wouldn't be the most common case for many userspace programs in any case. - Davide - 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/