Having Linux Persist Memory Changes to Disk

Does msync performance depend on the size of the provided range?

TL;DR: no it doesn't, kernel structures that hold the needed information are designed to make the operation efficient regardless of range size.

Pages of mappable objects are kept in a radix tree, however the Linux kernel implementation of radix trees has an additional special feature: entries can be marked with up to 3 different marks, and marked entries can be found and iterated on a lot faster. The actual data structure used is called "XArray", you can find more information about it in this LWN article or in Documentation/core-api/xarray.rst.

Dirty pages have a special mark which can be set (PAGECACHE_TAG_DIRTY) allowing for them to be quickly found when writeback is needed (e.g. msync, fsync, etc). Furthermore, XArrays provide an O(1) mechanism to check whether any entry exists with a given mark, so in the case of pages it can be quickly determined whether a writeback is needed at all even before looking for dirty pages.

In conclusion, you should not incur in a noticeable performance penalty when calling msync on the entire mapping as opposed to only a smaller range of actually modified pages.

What happens when two processes write to same portion of a mmaped file?

Yes, that's one of the purposes of memory mapping: as a form of "instantaneous IPC".

You must set the MAP_SHARED flag:

• http://man7.org/linux/man-pages/man2/mmap.2.html

If you wish to use shared memory for this purpose, I would consider the shminit()/shmat() APIs instead:

• http://linux.die.net/man/2/shmat

Suggestion: check out Beej's Guide to *nix Interprocess Communication:

• http://beej.us/guide/bgipc/

And no, if you use the raw mmap() APIs, there's no "before/after guarantee", and you must use some kind of locking (e.g. semaphores) if you wish to read/write data concurrently.

Also, from Understanding Memory Mapping:

Both the mmap and shmat services provide the capability for multiple
processes to map the same region of an object such that they share
addressability to that object. However, the mmap subroutine extends
this capability beyond that provided by the shmat subroutine by
allowing a relatively unlimited number of such mappings to be
established. While this capability increases the number of mappings
supported per file object or memory segment, it can prove inefficient
for applications in which many processes map the same file data into
their address space.

The mmap subroutine provides a unique object address for each process
that maps to an object. The software accomplishes this by providing
each process with a unique virtual address, known as an alias. The
shmat subroutine allows processes to share the addresses of the mapped
objects.

The above is true of any *nix variant, including both Linux and AIX.

memcached like software with disk persistence

I'd look at MongoDB. It caches things efficiently using your OS to page data in and out, and is pretty simple to setup. Redis and Memcached won't be good solutions for you because they keep everything in RAM. Other, simpler solutions like LevelDB or BDB would also probably be suitable. I don't think any database going to compute hashes automatically for you. It sounds like you already have code for this though.

---

Related Topics