Hi,
I've been thinking about your comment, and I realized it was a good
suggestion.
There are no problem with the zerocopy NFS, but If you want to
use UDP sendfile for streaming or something like that, you wouldn't
get good performance.
jakob> > the semaphore is required to serialize sending data as many knfsd kthreads
jakob> > use the same socket.
jakob>
jakob> Won't this serialize too much ? I mean, consider the situation where we
jakob> have file-A and file-B completely in cache, while file-C needs to be
jakob> read from the physical disk.
jakob>
jakob> Three different clients (A, B and C) request file-A, file-B and file-C
jakob> respectively. The send of file-C is started first, and the sends of files
jakob> A and B (which could commence immediately and complete at near wire-speed)
jakob> will now have to wait (leaving the NIC idle) until file-C is read from
jakob> the disks.
jakob>
jakob> Even if it's not the entire file but only a single NFS request (probably 8kB),
jakob> one disk seek (7ms) is still around 85 kB, or 10 8kB NFS requests (at 100Mbit).
jakob>
jakob> Or am I misunderstanding ? Will your UDP sendpage() queue the requests ?
There may be many threads on a streaming server and they would share
the same UDP socket. UDP_CORK mechanism requires semaphore to serialize
sending data and it would block each other for a long time because
sendfile() might have the threads sleep in BIO as you said.
You may say we can use MSG_MORE instead of UDP_CORK.
When we use it, we have to make multiple queue for each destination for
clientns. But we can't link pages to the queue as sendfile() have no
arguments specifying the destination.
client UDP sockets
+---------+
|dest:123 |---------+
| | |
+---------+ | server
V UDP socket
+---------+ +---------+ <--- thread1
|dest:123 |------->|src:123 | <--- thread2
| | |dest:ANY | <--- thread3
+---------+ +---------+ <--- thread4
A
+---------+ |
|dest:123 |---------+
| |
+---------+
Shall I make a multiple queue based on pid instead of destitation address ?
Any idea is welcome!
Thank you,
Hirokazu Takahashi
-
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/
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 22:00:20 EST