Paul J. Lucas writes:
> On Fri, 28 Jul 2000, Malcolm Beattie wrote:
>
> > Assuming the kernel only keeps track of the last fault position in the file,
> > it won't recognise that it's being read linearly (twice :-) and may well not
> > do the async read ahead and drop behind in page cache that it would do
> > otherwise. Once again, you'll lose performance with mmap.
>
> And reading in the file twice into two separate I/O buffers
> is better?
I've forgotten exactly what the original situation was so I'm not
sure whether it's better or not. With mmap you also have the
potential disadvantage that you're taking a page fault into the
kernel for every single page (say 4k or 8k) whereas with read(),
a single system call will fill up a much larger buffer with data.
It's also possible that the kernel can play tricks to get you the
data from a read better (on some architectures it could avoid
copying through the cache or it may be able to get the data
transferred from the source directly into your buffer without
passing through the CPU or suchlike).
Basically, mmap may well be an advantage from the ease or
elegance-of-coding point of view and in some cases it may win out
over read() for performance/scalability or whatever but it's not a
foregone conclusion and there are kernel/architecture-specific
difference which may swing the balance one way or the other. Now
we're getting offtopic though.
I really just wanted to make the points that saying "mmap is
always better than read" is not true and that there are things
going on behind the scenes.
--Malcolm
--
Malcolm Beattie <[EMAIL PROTECTED]> I am looking for a Linux (and
Unix Systems Programmer maybe Apache/mod_perl) job/contract
Oxford University Computing Services http://users.ox.ac.uk/~mbeattie/cv.html
