* Michael K. Edwards <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
