Please don't take this the wrong way, Ray, but I don't think _you_ understand the problem space that people are (or should be) trying to address here.
Servers want to always, always block. Not on a socket, not on a stat, not on any _one_ thing, but in a condition where the optimum number of concurrent I/O requests are outstanding (generally of several kinds with widely varying expected latencies). I have an embedded server I wrote that avoids forking internally for any reason, although it watches the damn serial port signals in parallel with handling network I/O, audio, and child processes that handle VoIP signaling protocols (which are separate processes because it was more practical to write them in a different language with mediocre embeddability). There's a lot of things that can block out there, not just disk I/O, but the only thing a genuinely scalable server process ever blocks on (apart from the odd spinlock) is a wait-for-IO-from-somewhere mechanism like select or epoll or kqueue (or even sleep() while awaiting SIGRT+n, or if it genuinely doesn't suck, the thread scheduler). Furthermore, not only do servers want to block rather than shove more I/O into the plumbing than it can handle without backing up, they also want to throttle the concurrency of requests at the kernel level *for the kernel's benefit*. In particular, a server wants to submit to the kernel a ton of stats and I/O in parallel, far more than it makes sense to actually issue concurrently, so that efficient sequencing of these requests can be left to the kernel. But the server wants to guide the kernel with regard to the ratios of concurrency appropriate to the various classes and the relative urgency of the individual requests within each class. The server also wants to be able to reprioritize groups of requests or cancel them altogether based on new information about hardware status and user behavior. Finally, the biggest argument against syslets/threadlets AFAICS is that -- if done incorrectly, as currently proposed -- they would unify the AIO and normal IO paths in the kernel. This would shackle AIO to the current semantics of synchronous syscalls, in which buffers are passed as bare pointers and exceptional results are tangled up with programming errors. This would, in turn, make it quite impossible for future hardware to pipeline and speculatively execute chains of AIO operations, leaving "syslets" to a few RDBMS programmers with time to burn. The unimproved ease of long term maintenance on the kernel (not to mention the complete failure to make the writing of _correct_, performant server code any easier) makes them unworthy of consideration for inclusion. So, while everybody has been talking about cached and non-cached cases, those are really total irrelevancies. The principal problem that needs solving is to model the process's pool of in-flight I/O requests, together with a much larger number of submitted but not yet issued requests whose results are foreseeably likely to be needed soon, using a data structure that efficiently supports _all_ of the operations needed, including bulk cancellation, reprioritization, and batch migration based on affinities among requests and locality to the correct I/O resources. Memory footprint and gentle-on-real-hardware scheduling are secondary, but also important, considerations. If you happen to be able to service certain things directly from cache, that's gravy -- but it's not very smart IMHO to put that central to your design process. 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/
