Messages in this thread | | | Date | Fri, 26 Jun 1998 10:30:21 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: Thread implementations... |
| |
Hi,
On Fri, 26 Jun 1998 07:19:47 +0200 (MET DST), MOLNAR Ingo <mingo@valerie.inf.elte.hu> said:
>> I can't see any advantage of sendfile() over push/pull other than a >> reduction in the number of system calls required to get the job done.
> no there is a much more important difference in favor of sendfile(), it's > the number of 'cursors' active within the system, and the timing of the > movement of these cursors and the coupling between them.
> Timing: eg., alone from the memory consumption point of view it's > perfectly possible to sendfile() a 500M file. With pull()+push(), we first > read it into the page cache, then write it out, we go through the page > cache twice.
If you are using the page cache, then true. There's no reason why pull and push _have_ to use the page cache, but it's probably simpler to implement that way. Likewise, there's no reason why sendfile() can't use it; again, however, the easiest implementation will probably do so.
> Coupling: much more important is the cache-utilization argument, if you > sufficiently slice up the work done within sendfile(), you will have the > 'freshly read' data still in some of the caches.
CPU cache, is this? Either sendfile() or pull/push will do the IO without any copies at all (assuming any remotely current motherboard with either scsi or dma-enabled ide) when reading from disk. The write (if it's to network, rather than to disk) is going to have to prime the cache either way; there's no difference between sendfile and pull/push from that respect.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |