> 1 - IO operations are still serialized at a very high level in the
> kernel. For example, it does not seem possible to read from a disk file
> at the same time as a write() is being processed to a socket. Is this
> correct, or did we miss some magic in the (un)lock-kernel() calls?
The fact that the kernel lock is released when blocking? While it
is true that two processors cannot be setting up I/O simultaneously
while we use the global kernel lock this is only a small part of
what happens during an I/O operation. Unless you have David Miller's
machine it isn't likely a big deal.
> 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.
Again this is marginal. A page belongs to a virtual memory space
which may have n tasks (threads) running in it. If the page is
stale (un-recently-referenced) then it is a candidate for freeing
*regardless* of how many tasks may potentially reference it in
the future, surely?
This might make more sense if he were talking about shared pages
(i.e. pages mapped in more than one VM space). In this case Linux
may unmap a page from one space even though it has been referenced
via another space. If the page is then accessed through the VM
space it was released from you take a fault that wasn't strictly
necessary since the page couldn't be released from memory yet.
This is related to VM spaces rather than threads though...
> 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.
No, I don't like that either (we're an Informix shop mainly :-) ). The
attitude in the past appears to have been that AIO can be done by
using a clone() to do it all from user space and this is, I believe,
the way that glibc 2.1 does it. (That approach is expensive if you
have a lot of AIO happening). If enough people want kernel-side AIO
I'll dust off my old code (it probably needs a lot of work still).
> My response to the above is that similar functionality could be gained
> with a combination of select() and non-blocking IO.
No, Select will tell you when it is possible to do more I/O, not
when a previous operation has completed. Non-blocking I/O simply
means that you will get an error rather than blocking until it
is possible to start your I/O. It does not mean that you can
start I/O and have it complete asynchronously while you do
something else.
One thing he has missed is the rather tired looking block I/O
layer we have. It could really do with cleaning up...
Mike
--
A train stops at a train station, a bus stops at a bus station.
On my desk I have a work station...
.----------------------------------------------------------------------.
| Mike Jagdis | Internet: mailto:mike@roan.co.uk |
| Roan Technology Ltd. | |
| 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 |
| RG40 1XG, ENGLAND | Fax: +44 118 989 1195 |
`----------------------------------------------------------------------'
-
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/