Question: I am using msync in my application on Linux 2.6 to ensure consistency in the event of a crash. I need to thoroughly test my usage of msync but the implementation seems to be flushing all the relevant pages for me. Is there a way to prevent automatic flushing of mmap'd pages onto the disk to expose erroneous usage of msync on my part?

Answer: 
With apologies to @samold, "swappiness" has nothing to do with this. Swappiness just affects how the kernel trades off swapping dirty anonymous pages versus evicting page cache pages when memory is low.

You need to play with the [Linux VM tunables controlling the pdflush task](http://www.westnet.com/~gsmith/content/linux-pdflush.htm). For starters, I would suggest:

```
sysctl -w vm.dirty_writeback_centisecs=360000

```

By default, `vm.dirty_writeback_centisecs` is 3000, which means the kernel will consider any dirty page older than 30 seconds to be "too old" and try to flush it to disk. By cranking it up to 1 hour, you should be able to avoid flushing dirty pages to disk at all, at least during a short test. Except...

```
sysctl -w vm.dirty_background_ratio=80

```

By default, `vm.dirty_background_ratio` is 10, as in 10 percent. That means when more than 10 percent of physical memory is occupied by dirty pages, the kernel will think it needs to get busy flushing something to disk, even if it is younger than `dirty_writeback_centisecs`. Crank this one up to 80 or 90 and the kernel should be willing to tolerate most of RAM being occupied by dirty pages. (I would not set this *too* high, though, since I bet nobody ever does that and it might trigger strange behavior.) Except...

```
sysctl -w vm.dirty_ratio=90

```

By default, `vm.dirty_ratio` is 40, which means once 40% of RAM is dirty pages, processes attempting to create more dirty pages will *block* until something gets evicted. Always make this one bigger than `dirty_background_ratio`. Hm, come to think of it, set this one before that one, just to make sure this one is always larger.

That's it for my initial suggestions. It is possible that your kernel will start evicting pages anyway; the Linux VM is a mysterious beast and seems to get tweaked on every release. Hopefully this provides a starting point.

See [Documentation/sysctl/vm.txt](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/sysctl/vm.txt) in the kernel sources for a complete list of VM tunables. (Preferably refer to the documentation for the kernel version you are actually using.)

Finally, use the [/proc/PID/pagemap interface](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/vm/pagemap.txt) to see which pages are actually dirty at any time.
A few guesses:

You can fiddle with the *swappiness* of the system via the `/proc/sys/vm/swappiness` tunable:

```none
   /proc/sys/vm/swappiness
          The value in this file controls how aggressively the
          kernel will swap memory pages.  Higher values increase
          agressiveness, lower values descrease aggressiveness.
          The default value is 60.

```

(Wow. `proc(5)` needs to be run through a spell-checker.)

If setting the `swappiness` to `0` doesn't do the trick, there are more tunable knobs; the `Documentation/laptops/laptop-mode.txt` file contains a good description of the `laptop_mode` script's behaviors:

```none
To increase the effectiveness of the laptop_mode strategy, the laptop_mode
control script increases dirty_expire_centisecs and dirty_writeback_centisecs in
/proc/sys/vm to about 10 minutes (by default), which means that pages that are
dirtied are not forced to be written to disk as often. The control script also
changes the dirty background ratio, so that background writeback of dirty pages
is not done anymore. Combined with a higher commit value (also 10 minutes) for
ext3 or ReiserFS filesystems (also done automatically by the control script),
this results in concentration of disk activity in a small time interval which
occurs only once every 10 minutes, or whenever the disk is forced to spin up by
a cache miss. The disk can then be spun down in the periods of inactivity.

```

You might wish to take these numbers to their extremes; if you're really curious about your application's behavior, it sounds reasonable to set these values quite high and see how long a `sync(1)` command takes when it's all done. But these are system-wide tunables -- other applications may not be so happy.