If one of these operations is sleeping the other may proceeed.
Although the bulk part of the socket write happens inside lock_kernel,
the messy work (e.g. handling TCP acks, handle TCP input, handle TCP
retransmit) happens inside a bottom half, which may proceed in parallel
on another CPU (in 2.1/2.2)
So in benchmark situations (putting packets as fast on a wire as possible)
it is mostly serialized, but in real world situtations (communicating with
lots of targets that lose lots of packets) Linux works better. Also note
that the internal IO layering of Linux has much less overhead than that of
NT or other Unixes, so although we use a giant lock less cycles are still
spent, simply because the critical region is shorter and because the
the actual locking overhead of locking every single resource goes away
(upto 4 CPUs or so this seems to have positive cache effects, because it
avoids cache line ping-pong between the CPUs).
Of course in future Linux will go to a more finegrained locking too in
future.
>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.
When NT needs special threads tuning for that - how does it handle
shared memory then ? ;)
-Andi
-
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/