[lkml]   [2007]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

* Ingo Molnar <> wrote:

> Firstly, i dont think you are fully applying the syslet/threadlet
> model. There is no reason why an 'idle' client would have to use up a
> full thread! It all depends on how you use syslets/threadlets, and how
> (frequently) you queue back requests from cachemiss threads back to
> the primary thread. It is only the simplest queueing model where there
> is one thread per request that is currently blocked.
> Syslets/threadlets do /not/ force request processing to be performed
> in the async context forever - the async thread could very much queue
> it back to the primary context. (That's in essence what Tux did.) So
> the same state-machine techniques can be applied on both the syslet
> and the threadlet model, but in much more natural (and thus lower
> overhead) points: /between/ system calls and not in the middle of
> them. There are a number of measures that can be used to keep the
> number of parallel threads down.

i think the best model here is to use kevents or epoll to discover
accept()-able or recv()-able keepalive sockets, and to do the main
request loop via syslets/threadlets, with a 'queue back to the main
context if we went async and if the request is done' feedback mechanism
that keeps the size of the pool down.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-22 16:07    [W:0.147 / U:18.912 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site