[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

* Michael K. Edwards <> wrote:

> [...] As for threadlets, making them kernel threads is not such a good
> design feature, O(1) scheduler or not. You take the full hit of
> kernel task creation, on the spot, for every threadlet that blocks.
> [...]

this is very much not how they work. Threadlets share the same basic
infrastructure with syslets and they do /not/ take a 'full hit of kernel
thread creation' when they block. Please read the announcements, past
discussions on lkml and the code about how it works.

about your other point:

> > threadlets, when they block, are regular kernel threads, so the
> > regular O(1) scheduler takes care of them. If MMU trashing is of any
> > concern then syslets should be used to implement the most
> > performance-critical events: under Linux a kernel thread that does
> > not exit out to user-space does not do any TLB switching at all.
> > (even if there are multiple processes active and their syslets
> > intermix)
> As far as I am concerned syslets by themselves are a dead letter,
> because you can't do any of the things that potential application
> coders need to do with them. [...]

syslets are not meant to be directly exposed to application coders.
Syslets (like many of my previous mails stated) are meant as building
blocks to higher-level AIO interfaces such as in glibc or libaio. Then
user-space can build its state-machine based on syslet-implemented
glibc/libaio. In that specific role they are a very fast and scalable

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 07:59    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean