Has he only looked at the 2.0.x series? In 2.1.x the global kernel
lock is held *while the task is running*. In other words, if the
reading process has been context switched out (while waiting for data
to be read from media) then it gives up the global kernel lock. That
means another process can do a write() on a socket and will not be
blocked when it asks for the global kernel lock.
In 2.3.x even this grabbing of the global kernel lock will be
removed. Currently, the situation is not as bad as the author made
out.
> 2 - Since the kernel does not have any notion of threads, it cannot
> optimize things such as memory management. To quote Mr. Russinovich
> directly:
>
> I'm referring to the OS correct management of the physical memory
> that has been assigned to the set of clones - it will trim/expand
> the memory under the assumption that each is separate. This will
> not cause incorrect behavior, but may introduce inefficiency and
> is further evidence that the thread support has only begun.
This is completely wrong. Linux has kernel-based threads, and those
threads share the same virtual memory space. These threads share the
same page tables and hence the same physical memory.
That the author can even say this astounds me, since Linux has had
it's current model of threads for years.
> 3 - Not directly related to threading support, but more of a
> "supporting enterprise-level applications" issue: The current kernel
> does not support asynchronus IO. E.g, there is no mechanism to
> issue write()s on several file descriptors and get notified of the
> status of those write()s at a later time.
A few months back Richard Henderson submitted a patch for kernel
support of efficient AIO notification. IIRC glibc 2.recent has made
use of this.
> The main goal of the async IO (at least, as far as this discussion
> is concerned) is to avoid having a separate thread for each
> connected client in a server process. One thread-per-CPU is the
> most effecient state for a server process, because it avoids context
> switches. Async IO would allow each thread to service multiple
> clients.
This is all motherhood and apple pie stuff (to quote the American
vernacular). Grab your pie from your nearest Linux mirror. Mothers not
included.
> My response to the above is that similar functionality could be
> gained with a combination of select() and non-blocking IO. However,
> this combination would seem to generate excessive context switches
> and user<->kernel space transfers, and non-blocking IO is not
> particularly useful for disk files. It does have the advantage of
> getting immediate error reporting however...
Far better to use the efficient AIO support in 2.1.x.
> So, are context switches are so effecient that the
> one-thread-per-client model is the best way to go, and there would
> be no real performance gain in implementing async IO? If not,
> perhaps this should be a goal of the 2.3 series...
While Linux context switches are very fast, I think you're still
better off with the AIO support.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/