On Jul 30, 3:51am, Andi Kleen wrote:
> > Couldn't that be taken care of, by implementing copy-on-write semantics
> > on the user-level page that has been (hypothetically) remapped by
> > the "copy agent"? It would seem that the common case would be not to
> > modify the data buffer that was just read, and the copy-on-write would
> > be typically unneeded.
>
> Write protecting pages is very expensive, especially on SMP machines where
> the TLB updates may have to be broadcasted to other CPUs when you have
> multiple threads.
Good point. Still, it would seem that on SP systems, and certain cases
of large read requests this might be a win?
A bit off-topic, but does a typical x86-based PC have the capability
of performing memory-to-memory copies via DMA? How large would the
transfer have to be for something like this to justify the overhead?
(I suppose it would require taking interrupt to signal completion?)
>
> >
> > Does glibc implement fread() and friends using mmap(), when reading
> > from a file? Would there be something to be gained from that?
> > Alternatively, if the file system implemented zero copy semantics
> > in read(), there'd be no need to push the optimization to a higer
> > level (ie, into glibc).
>
> Why asking when you can easily check yourself ?
>
Heh, well I just checked glibc-2.0.7, and it doesn't look to me as if
it uses mmap() to accelerate fread().
The other part of my question was whether anyone had an estimate on how
much is saved by using mmap() and avoiding the copy on read?
