Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

Ingo Molnar
2007-02-22T06:56:33Z

* Michael K. Edwards <medwards.linux@gmail.com> 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
mechanism.

Ingo