== How _mmap(2)_ requires a unified buffer cache

In a [[previous entry UnifiedBufferCache]] I mentioned that Sun's
addition of _mmap()_ basically forced their hand on having a unified
buffer cache. Today I feel like elaborating on that.

The problem with having _mmap()_ and not a unified buffer cache is page
coherence. If you have some programs using _mmap()_ and some using
regular _read()_ and _write()_, you will wind up with two copies of
pages, one mapped into process memory and one in the buffer cache.
Because virtual memory and the buffer cache are not unified, there is
nothing that keeps these two copies in sync with each other; programs
will see an unpredictable mix of new and old data, depending on what
pages got forced out of virtual memory when.

(A related problem is finding already-mapped pages so that you can
share mappings across processes, which means you're going to need
some sort of mapping index anyways.)

Since you want to let people _mmap()_ more file pages than you have
buffer cache, you can't just have _mmap()_ use the buffer cache to hold
mapped in file pages. You can reuse your mapping indexing scheme to
create coherence without technically having a unified buffer cache, but
I think that there would be various issues and you're so close to a
unified buffer cache that you might as well go the rest of the way.

(The one benefit of not unifying the buffer cache is that at least
theoretically you have a clear way to avoid [[file IO eating your
virtual memory system UnifiedCacheDownside]].)