Re: [patch 05/11] syslets: core code

[Ingo Molnar <mingo@elte.hu>]

* Alan <alan@lxorguk.ukuu.org.uk> wrote:

> >    this "AIO atom" in the first place, WHICH WE KNOW IS INCORRECT, 
> >    since current users use "aio_read()" that simply doesn't have 
> >    that and doesn't build up any such data structures.
> 
> Do current users do this because that is all they have, because it is 
> hard, or because the current option is all that makes sense ?
> 
> The ability to avoid asynchronous completion waits and 
> complete/wake/despatch cycles is a good thing of itself. [...]

yeah, that's another key thing. I do plan to provide a sys_upcall() 
syscall as well which calls a 5-parameter user-space function with a 
special stack. (it's like a lightweight signal/event handler, without 
any of the signal handler legacies and overhead - it's like a reverse 
system call - a "user call". Obviously pure userspace would never use 
sys_upcall(), unless as an act of sheer masochism.)

[ that way say a full HTTP request could be done by an asynchronous
  context, because the HTTP parser could be done as a sys_upcall(). ]

so if it's simpler/easier for a syslet to do a step in user-space - as 
long as it's an 'atom' of processing - it can be done.

or if processing is so heavily in user-space that most of the logic 
lives there then just use plain pthreads. There's just no point in 
moving complex user-space code to the syslet side if it's easier/faster 
to do it in user-space. Syslets are there for asynchronous /kernel/ 
execution, and is centered around how the kernel does stuff: system 
calls.

besides sys_upcall() i also plan two other extensions:

 - a CLONE_ASYNC_WORKER for user-space to be able use its pthread as an
   optional worker thread in the async engine. A thread executing
   user-space code qualifies as a 'busy' thread - it has to call into
   sys_async_cachemiss_thread() to 'offer' itself as a ready thread that
   the 'head' could switch to anytime.

 - support for multiple heads sharing the async context pool. All the
   locking logic is there already (because cachemiss threads can already
   access the queue), it only needs a refcount in struct async_head
   (only accessed during fork/exit), and an update to the teardown logic
   (that too is a slowpath).

	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/