Paul J. Lucas writes:
> > This is the quote from "Philip and Alex..." that I was talking about
> > earlier. I don't know if its relevant or not:
> >
> > They replied "NaviServer uses memory-mapped file I/O on single-processor
> > machines but automatically configures itself to use operating system read on
> > multi-CPU machines so as to reduce shared memory contention."
>
> mmap(2) is *supposed* to share memory when read-only which is
> what's beign done for HTML file reads, so I don't understand
> what "contention" there could possibly be.
That's where some of the subtlety comes in. The first that springs
to mind is that with multiple CPUs of an architecture with a
virtually indexed cache, if the mmap maps the file at different
virtual addresses (as it very well may without slow global
communication between the reading processes) then the data will end
up being duplicated in processor cache. That slows things down.
Another point is that it can be harder for the kernel to notice
when a file is being read linearly when all it sees is page faults
through an address space. That means it may not do read-ahead on
that file as well. Most decent Unices will probably try to keep
track these days (certainly Linux does page-ahead and in fact
page-around to try to predict when to read-ahead or drop-behind
or whatever). On the other hand, if you have two concurrent
processes doing the reading then you'll get page faults at, for
example, byte 8k, 16k, 8k(second process starting), 24k, 16k and
so on. 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.
--Malcolm
--
Malcolm Beattie <[EMAIL PROTECTED]>
Unix Systems Programmer
Oxford University Computing Services
