5 ms·

>It can be written in a few lines of efficient user code. I'm not sure he's understanding what this is. There is no copying needed here at all. The kernel co

>It can be written in a few lines of efficient user code. I'm not sure he's understanding what this is. There is no copying needed here at all. The kernel could make the hard drive write to a place in memory, have the NIC read from that place and just manage interrupts between the two. The kernel wouldn't have to touch the data at all. This may not be how Linux does it (given the requirement for a memmap'able file descriptor) but that would be possible at least. I don't think you could do anything near this in user code.

acqq 16y ago
By having mmap you avoid copying from the kernel RAM space to the user RAM space, mmap makes both sharing the same chunk, therefore the restriction for the thing being mmapable. If you don't allow mmap the system will certainly have to copy between kernel and user memory (in both directions with separate read and write calls).
- loewenskind 16y ago
  No, sendfile takes a file descriptor and forwards the contents to a socket. It wouldn't have to mmap the file because the user code never touches the file data. This is probably why other OSes that support sendfile don't have this restriction. >If you don't allow mmap the system will certainly have to copy between kernel and user memory Why? All the kernel has to do is set the DMA location for the drive to be a kernel buffer and follow any inodes when the file is split up on the disk. The NIC driver can just be told to load the data from those locations directly so no kernel copying at all, much less into user space.
  - acqq 16y ago
    > Why? I wrote about mmap in the context of separate write and read calls (i.e. no senddata call exists), not in the context of senddata.
kmavm 16y ago
Rob Pike deserves the benefit of your doubt when discussing UNIX implementations. http://en.wikipedia.org/wiki/Rob_Pike http://en.wikipedia.org/wiki/Rob_Pike The read(2)/write(2) solution from userspace would involve no copying as well, assuming a competent kernel implementation. The only "overheads" to speak of relative to what's possible with sendfile("2") would be those associated with writing one contiguous page table entry for every 4KB of data to set up the mappings; since sendfile(2) requires that you use mmap'able input, it probably incurs the same overheads. Fine, let's say doing the right thing with read(2)/write(2) is hard, even really hard, and sendfile(2) is faster today. Making expedient shortcuts to performance in the system call API has historically not turned out well in UNIX. People write software which depends on this interface, and that software may well outlive any existing hardware and its quirks.
- acqq 16y ago
  Classic read and write pointer can have any address, it doesn't have to be a multiple of kernel page size or whatever. Is OS supposed to implicitly do a new "hidden" mmap whenever it sees an address that's multiple of the page size? And to do the lookups for matching chunk still mmaped for every write? How long are you going to keep such relations at all in the system with more reads and writes in progress? I don't see how that concept can be made efficient, and Pike doesn't actually explain in the post how he'd do it. sendfile looks ugly and inelegant but solves a real problem.
- rlpb 16y ago
  > The read(2)/write(2) solution from userspace would involve no copying as well, assuming a competent kernel implementation. Wouldn't the userspace application have to ensure that the buffers being passed to read(2) and write(2) are page-aligned?
  - deleted 16y ago
    [deleted]
  - wmf 16y ago
    I think the kernel could copy the un-page-aligned head and tail while remapping the body.

acqq 16y ago

By having mmap you avoid copying from the kernel RAM space to the user RAM space, mmap makes both sharing the same chunk, therefore the restriction for the thing being mmapable. If you don't allow mmap the system will certainly have to copy between kernel and user memory (in both directions with separate read and write calls).

loewenskind 16y ago
No, sendfile takes a file descriptor and forwards the contents to a socket. It wouldn't have to mmap the file because the user code never touches the file data. This is probably why other OSes that support sendfile don't have this restriction. >If you don't allow mmap the system will certainly have to copy between kernel and user memory Why? All the kernel has to do is set the DMA location for the drive to be a kernel buffer and follow any inodes when the file is split up on the disk. The NIC driver can just be told to load the data from those locations directly so no kernel copying at all, much less into user space.
- acqq 16y ago
  > Why? I wrote about mmap in the context of separate write and read calls (i.e. no senddata call exists), not in the context of senddata.

kmavm 16y ago

Rob Pike deserves the benefit of your doubt when discussing UNIX implementations. http://en.wikipedia.org/wiki/Rob_Pike http://en.wikipedia.org/wiki/Rob_Pike The read(2)/write(2) solution from userspace would involve no copying as well, assuming a competent kernel implementation. The only "overheads" to speak of relative to what's possible with sendfile("2") would be those associated with writing one contiguous page table entry for every 4KB of data to set up the mappings; since sendfile(2) requires that you use mmap'able input, it probably incurs the same overheads. Fine, let's say doing the right thing with read(2)/write(2) is hard, even really hard, and sendfile(2) is faster today. Making expedient shortcuts to performance in the system call API has historically not turned out well in UNIX. People write software which depends on this interface, and that software may well outlive any existing hardware and its quirks.

acqq 16y ago
Classic read and write pointer can have any address, it doesn't have to be a multiple of kernel page size or whatever. Is OS supposed to implicitly do a new "hidden" mmap whenever it sees an address that's multiple of the page size? And to do the lookups for matching chunk still mmaped for every write? How long are you going to keep such relations at all in the system with more reads and writes in progress? I don't see how that concept can be made efficient, and Pike doesn't actually explain in the post how he'd do it. sendfile looks ugly and inelegant but solves a real problem.
rlpb 16y ago
> The read(2)/write(2) solution from userspace would involve no copying as well, assuming a competent kernel implementation. Wouldn't the userspace application have to ensure that the buffers being passed to read(2) and write(2) are page-aligned?
- deleted 16y ago
  [deleted]
- wmf 16y ago
  I think the kernel could copy the un-page-aligned head and tail while remapping the body.