implementation of dirty_expire_centisecs

Question

I'm trying to understand the behavior of dirty_expire_centisecs parameter on servers with 2.6 and 3.0 kernels.

Kernel documentation says (vm.txt/dirty_expire_centisecs) "Data which has been dirty in-memory for longer than this interval will be written out next time a flusher thread wakes up."

which implies, dirty data that has been in memory for shorter than this interval will not be written.

According to my testing, behavior of dirty_expire_centisecs is as follows: when writeback timer fires before the expire timer, then no pages will be flushed, else all pages will be flushed. If background_bytes limit reaches, it flushes all or portion depending on the rate, independent of both timers.

My testing tells me at low write rates (less than 1MB per sec), dirty_background_bytes trigger will flush all dirty pages and at slightly higher data rates (higher than 2MB per sec), it flushes only a portion of the dirty data, independent of expiry value.

This is different from what is said in the vm.txt. It make sense not to flush the most recent data. To me, observed behavior is not logical and practically useless. What do you guys think ?

My test setup: Server with 16GB of RAM running Suse 11 SP1, SP2 and RedHat 6.2 (multi boot setup)

vm.dirty_bytes = 50000000            // 50MB <br>
vm.dirty_background_bytes = 30000000 // 30MB <br>
vm.dirty_writeback_centisecs = 1000  // 10 seconds <br>
vm.dirty_expire_centisecs = 1500     // 15 seconds <br>

with a file writing tool where I can control the write()'s per sec rate and size.

Answer 1

I asked this question on the linux-kernel mailing list and got an answer from Jan Kara. The timestamp that expiration is based on is the modtime of the inode of the file. Thus, multiple pages dirtied in the same file will all be written when the expiration time occurs because they're all associated with the same inode.

http://lkml.indiana.edu/hypermail/linux/kernel/1309.1/01585.html