i was a bit shocked when i checked the diskstats from my Cm 7.2 and saw, that only about 5 - 10% of the readings from the /system /cache partition are actuallly merged.
Now i asked myself why was that?
Linux has a function called read ahead, which tells the system to read further then it actually needs. Not a bad thing, considering it is very likely that you will need object B, once you called object A.
The problem with a too high value for read ahead is once you red object A, the one that you were looking for, the system is going to call for object B, C, D, E, F, G, and so on... Now you might also need object B, maybe even C, but it gets more unlikely that you will need all the following data as well...
This information will just be flushed from the memory, hence only 5 - 10% of the readings are actually merged.
Digging a bit deeper reveals read ahead values of 768kb for the /system and /cache partition, which seems a bit pointless to me, especially on the cache partition. (Bear in mind, linux default is 4kb)
So i called:
C:\adb>adb shell cat /proc/self/mountinfo 1 1 0:1 / / rw,relatime - rootfs rootfs rw 11 1 0:11 / /dev rw,relatime - tmpfs tmpfs rw,mode=755 12 11 0:9 / /dev/pts rw,relatime - devpts devpts rw,mode=600 13 1 0:3 / /proc rw,relatime - proc proc rw 14 1 0:12 / /sys rw,relatime - sysfs sysfs rw 15 1 0:13 / /acct rw,relatime - cgroup none rw,cpuacct 16 1 0:14 / /mnt/asec rw,relatime - tmpfs tmpfs rw,mode=755,gid=1000 17 1 0:15 / /mnt/obb rw,relatime - tmpfs tmpfs rw,mode=755,gid=1000 18 11 0:16 / /dev/cpuctl rw,relatime - cgroup none rw,cpu 19 1 138:12 / /system rw,relatime - ext4 /dev/block/stl12 rw,barrier=1,data=ordered 20 1 138:13 / /data rw,nosuid,nodev,relatime - ext4 /dev/block/stl13 rw,barrier=1,data=ordered 21 1 138:14 / /cache rw,nosuid,nodev,relatime - ext4 /dev/block/stl14 rw,barrier=1,data=ordered 22 21 138:13 /local/download /cache/download rw,nosuid,nodev,relatime - ext4 /dev/block/stl13 rw,barrier=1,data=ordered 23 20 179:2 / /data/sdext2 rw,relatime - ext4 /dev/block/mmcblk0p2 rw,barrier=1,data=ordered 24 1 179:1 / /mnt/sdcard rw,nosuid,nodev,noexec,relatime - vfat /dev/block/vold/179:1 rw,dirsync,uid=1000,gid=1015,fmask=0602,dmask=0602,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 25 1 179:1 /.android_secure /mnt/secure/asec rw,nosuid,nodev,noexec,relatime - vfat /dev/block/vold/179:1rw,dirsync,uid=1000,gid=1015,fmask=0602,dmask=0602,allow_utime=0020,codepage=cp437,iocharset=iso88591,shortname=mixed,utf8,errors=remount-ro 26 24 0:17 / /mnt/sdcard/.android_secure ro,relatime - tmpfs tmpfs ro,size=0k,mode=000
# Read Ahead write /sys/block/mmcblk0/bdi/read_ahead_kb 512 write /sys/block/mmcblk0p2/bdi/read_ahead_kb 512 write /sys/block/stl12/queue/read_ahead_kb 4 write /sys/block/stl13/queue/read_ahead_kb 4 write /sys/block/stl14/queue/read_ahead_kb 4 write /sys/devices/virtual/block/stl12/queue/read_ahead_kb 4 write /sys/devices/virtual/block/stl13/queue/read_ahead_kb 4 write /sys/devices/virtual/block/stl14/queue/read_ahead_kb 4
I now have about 30% of my readings actually merged and i guess that is way better.
If you want to confirm, that you have done everything right, browse to:
where x:x should be replaced by:
179:1 / 179:2 / 179:0 for the sdcard 138:12 for the /system partition 138:13 for the /data partition 138:14 for the /cache partition
I do have the feeling, that my phone is a lot snappier then before... Also my battery seems to last longer... All this might of course be a placebo, also it does make sense (Less readings should result in less battery consumption and of course free up some ressources).
If someone knows a bit more on that topic (And why the values were 768kb in the first place anyway...) i would be happy to learn more about it.
Edit: I included this in the Badass Kernel for Gingerbread from alin.p (Just the Kernel, not the keylayout!)
This is not my work, but alin.p's!