> We could solve this problem by introducing a new mmap flag: MAP_DB.
> Data mapped using this would _not_ spontaneously get written back to
> the mapped file. It would only get paged in from the file, and paged
> to swap, if memory is tight. An explicit msync() would be needed to
> sync it to disk (to be issued at commit). Or even better: an new
> mcoherent() syscall, to be issued at commit, which would _allow_ the
> kernel to copy the data to the file, without forcing it to do so
> immediately. The advantage of this latter approach would be a better
> commit latency.
i've just checked Postgres95 sources, and they use shared memory (called
SysCache) as a write-cache, thus they do double buffering. [their design
looks quite OK otherwise]
the problem with a MAP_DB flag is that it possibly penaltizes >all< memory
operations [and we need no RDBMS functionality in the kernel if we run a
simple web server]. It makes bdflush more complex. [we could in turn
rename it to dbflush =B-)]. And i'm not sure wether such functionality is
conceptually necessary in the kernel.
but vmareas with nondefault paging operators look like an intriquing
option :) [and they are already possible in the kernel? ... at least some
bits are there already :)]
[but show me the right way if i'm on the wrong track]
-- mingo