[Samsung Galaxy Mini] Wooaarr:
Changing read ahead values

Hello there,

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:

proc/self/mountinfo

to get a detailed info about the partitions. (Importent part in bold)

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
[SIZE="4"][B]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[/B][/SIZE]
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

Adding the following lines to init.gt-s5570.rc in the kernel ramdisk, changes the default read ahead value (768 :eek:) to smaller ones.

# 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

/sdcard (including sdext) 512kb (Maybe not optimal if you use a swap file)

/system 4kb

/cache 4kb

/data 4kb

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:

sys/devices/virtual/bdi/x:x

where x:x should be replaced by:

[I]179:1 / 179:2 / 179:0 for the [B]sdcard[/B]
138:12 for the [B]/system[/B] partition
138:13 for the [B]/data[/B] partition
138:14 for the [B]/cache[/B] partition[/I]

Now look for the read_ahead_kb file, open it and confirm the value.

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.

Take care

Wooaarr

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!