On 2/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
threadlets (and syslets) are parallel contexts and they behave so - queuing and execution semantics are then ontop of that, implemented either by glibc, or implemented by the application. There is no 'pipeline' of requests imposed - the structure of pending requests is totally free-form. For example in threadlet-test.c i've in essence implemented a 'set of requests' with the submission site only interested in whether all requests are done or not - but any stricter (or even looser) semantics and ordering can be used too.
In short, you have a dataflow model with infinite parallelism, implemented using threads of control mapped willy-nilly onto the underlying hardware. This has not proven to be a successful model in the past.
in terms of AIO, the best queueing model is i think what the kernel uses internally: freely ordered, with barrier support. (That is equivalent to a "queue of sets", where the queue are the barriers, and the sets are the requests within barriers. If there is no barrier pending then there's just one large freely-ordered set of requests.)
That's a big part of why Linux scales poorly for workloads that involve a large volume of in-flight I/O transactions. Unless you essentially lock one application thread to each CPU core, with a complete understanding of its cache sharing and latency relationships to all the other cores, and do your own userspace I/O scheduling and dispatching state machine -- which is what all industrial-strength databases and other sorts of transaction engines currently do -- you get the same old best-effort context-thrashing scheduler we've had since Solaris 2.0. Let's do something genuinely better this time, OK? Cheers, - Michael - 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/