[patch 00/14] Syslets, generic asynchronous system call support, v2

[Ingo Molnar <mingo@elte.hu>]

this is the v2 release of the syslet subsystem. This is an interim 
release, not all known and pending items are fixed/changed yet - the 
tree is still work in progress:

   http://redhat.com/~mingo/syslet-patches/

The biggest conceptual change in v2 is the ability of cachemiss threads 
to be turned into user threads. This fixes signal handling, makes them 
ptrace-eable, etc. (I've updated the sample userspace code at the URL 
above to also do user-space cachemiss processing - just Ctrl-Z the 
async-test.c run to trigger it action.)

Things not yet done in v2 and planned for v3:

 - multiple completion rings support

 - share the 'spare thread' between multiple rings, to further reduce 
   startup costs.

 - remove mlock() reliance

Changes since v1:

 - FPU support fixed: detach FPU state from kernel thread state 
   (implemented by Arjan van de Ven)

 - remove superfluous CLONE_VM from create_async_thread()
   (noticed by Jens Axboe)

 - sys_umem_add() does not ignore -EFAULT of __put_user()
   (noticed by Andrew Morton)

 - use VERIFY_READ instead of VERIFY_WRITE in copy_uatom()
   (noticed by Andrew Morton)

 - move schedule() to tail of loop in cachemiss_loop()
   (noticed by Andrew Morton)

 - added move_user_context() arch op

 - added async_syscall() and recursion protection against re-entry of 
   sys_async_exec(), sys_fork()/sys_clone(), etc.

 - added sys_async_thread() call - a user-space thread can thus call 
   back into the syslet subsystem and continue cachemiss work.

 - further cleanups in the include files

 - race fixes to sys_async_wait()

 - optimized out the kmalloc()/kfree() of the async_head

 - async_thread structure not on the kernel stack anymore, to allow 
   async contexts to run user-space.

 - added support for head_stack and head_eip to enable the initial 
   thread/task to run a cachemiss user context too, if it gets turned 
   into a cachemiss thread.

As always, comments, suggestions, reports are welcome.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/