Messages in this thread | | | Date | Wed, 21 Feb 2007 17:04:45 -0800 | From | "Michael K. Edwards" <> | Subject | Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3 |
| |
On 2/21/07, Ingo Molnar <mingo@elte.hu> 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 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/
| |