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

[Ingo Molnar <mingo@elte.hu>]

* 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
-
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/