Increasing readahead in a not completely retarded manner

424 posts
Thanks Meter: 199
By glitterballs, Retired Recognized Developer on 12th April 2011, 03:40 PM
Post Reply Email Thread
So...there have been some reports going around on reddit and, here I guess, that increasing readahead will make your sd card faster, and maybe some of you noticed that on my build from early March that I had changed the default readahead values as well. And, the truth is, that it generally does, but the reason the mainline kernel tree doesn't have a higher readahead value isn't because some kernel "developers" here are smarter than Linus and everyone else, but because it is generally a bad idea, and the way some kernel "developers" have implemented it, it is an almost unbelievably stupid way to do it.

So, to give a little background about why the way some people implemented it is a really bad idea...readahead works like this - when you need a section of data from the disk, the kernel will grab that data, and anticipating you'll also use the next X number of kb, it will also grab that data as well and put it into memory. So, when you're doing something like listening to music, or copying data from an sd card (ie long sequential file reads), having a larger readahead is a good thing, and will speed up the process and make things more efficient. But when you aren't doing long sequential reads, you end up thrashing your data. In other words, if you set the readahead value to, let's say 1024kb on /system, every time you access a file you're reading ahead the data that you need, plus and additional 1024kb, or to the end of the file (wouldn't make much sense to read ahead past the end of a file). If you don't end up using that 1024kb it gets flushed from memory, and you read ahead on some other file by 1024kb. You don't end up using that section of data from readahead, it gets flushed, etc, etc. It's a tremendously stupid waste of resources to read ahead that much when you aren't using it. I mean, there's a reason why some of these things are tunable in the kernel and not set to higher values.

And if you want some serious proof check diskstats. With readahead set to 128kb on /system, I still have less than 10% of reads merged. If you only have 10% of reads merged with a 128kb readahead, why on earth (unless you don't know what you're doing) would you want to increase readahead to 1024kb?! To take this one step farther, with readahead set to 4kb, I still only have about 1/3 of the reads merged.

Isn't there a better way to increase readahead?
Yes. The better way is to use Wu Fengguang's series of patches found here The end result of these patches is that /system, /cache and /dbdata have readahead values of 4kb, /data and your internal and external sd cards have readahead set to 512kb. If you want to take it a step farther and increase it to 1024kb (or whatever value you happen to like - note that you get to a point where you don't get any more throughput, I wouldn't go beyond 1024kb personally), you can do it manually at
echo XXXX > /sys/devices/platform/s3c-sdhci.0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/queue/read_ahead_kb
(internal) and
echo XXXX > /sys/devices/platform/s3c-sdhci.2/mmc_host/mmc2/mmc2:bf2e/block/mmcblk1/queue/read_ahead_kb

What I do is have scripts set up in Gscript lite to increase and decrease readahead, but I don't even use these all the time. Also, if you don't want to flash kernels just to do this, you can set the readahead value for any drive manually, just like for the sd cards,

echo XX > /sys/devices/virtual/block/stl9/queue/read_ahead_kb
echo XX > /sys/devices/virtual/block/stl10/queue/read_ahead_kb
(no point in increasing readahead on /cache, and really, really, really no point in doing it on bml or the other block

In other news...I promise I'll be back soon. I bought a house partially on a whim, partially to spite my girlfriend, and I've been rather busy tweaking the place I live in instead of my phone. But, I just started sorting through the patches I made to my personal sources and I will hopefully have it done tonight...(I know, I've said that many times before, but this time I'm serious...I think)

edit - as an aside, if you've ever wanted to have your display be at the lowered light setting that it switches to just before the screen automagically shuts off, you can control that as well at
echo 1 > /sys/devices/platform/s3cfb/spi_gpio.3/spi3.0/backlight/s5p_bl/brightness
it doesn't have to be 1, any value from 1-20 seems to have the same brightness, to my eyes at least. Again, I have this set up as a script in Gscript and if I want to dim the display a bit more I run this have to use it every time you unlock the display or if you get close to the screen timeout limit and then touch the screen again.
The Following 40 Users Say Thank You to glitterballs For This Useful Post: [ View ] Gift glitterballs Ad-Free
12th April 2011, 04:45 PM |#2  
phlunkie's Avatar
Senior Member
Flag florida
Thanks Meter: 115
good read and explanation. thanks
12th April 2011, 06:24 PM |#3  
Senior Member
Thanks Meter: 679
im guessing the new kernel will have the above mentioned readahead mods? cant wait!
23rd February 2013, 03:58 PM |#4  
Thanks Meter: 12
Thank you man. This is the only useful description about readahead I've ever read and confirms that kernel default value is not so stupid as it looks.
24th February 2013, 03:00 PM |#5  
Flag Bangalore
Thanks Meter: 3
so, is it a good idea to increase readahead if the only files on the sd card are mp3's, jpeg's and documents?
28th February 2014, 04:49 PM |#6  
themichael's Avatar
Senior Member
Flag New York
Thanks Meter: 152
Donate to Me
Originally Posted by npt1988

so, is it a good idea to increase readahead if the only files on the sd card are mp3's, jpeg's and documents?

Yeh, bigger files that are streamed like movies or music will benefit from a higher read ahead. Smaller files like word docs might not.
19th January 2019, 03:24 PM |#7  
just to make things more clear...
The content of read_ahead_kb is numeric,

You can use echo line-above,
but you have to make sure that you replace the
XXXX (or XX) in the line with 512.

Here is where you can find multiple read_ahead_kb files in most of the Samsung devices,
it is mostly related to amount of devices (external, potential and internal-storage).

As far as I can see, each read_ahead_kb,
has the value 128 followed by a single new-line (Unix end-of-line, a.k.a \n or 10 in ASCII.

For Samsung devices,
Kernel/block/blk-sysfs.c and Kernel/mm/backing-dev.c are the files reading/using the files/values.
you can view just those two file in here (instead of downloading the whole code, if you wish to know what those files actually does):
20th September 2019, 06:42 AM |#8  
Hellboy4's Avatar
Senior Member
Flag melbourne
Thanks Meter: 29
just curious to know. will high readahead kb use more battery?

11th October 2019, 01:35 PM |#9  
xFirefly93's Avatar
Senior Member
Flag Timrå
Thanks Meter: 2,302
Donate to Me
Originally Posted by Hellboy4

just curious to know. will high readahead kb use more battery?


Better to use 128kb for all existing IO blocks.
30th March 2020, 03:36 AM |#10  
Junior Member
Thanks Meter: 0
how increase read ahead cache and sdcard to 2048 in phoenix os
Hello XDA memebers and admin
i need help and very tired
i dont want use L speed in phoenix os for boost phone and speed read and write
i need other apk or code or tweak
please help me
15th April 2020, 03:46 PM |#11  
3c's Avatar
Senior Member
Thanks Meter: 1,839
Donate to Me
Thanks for this useful post, which reminds me a few years ago every root user wanted to increase readahead. So I built a tool to actually test and compare read-speed when setting different readahead values.

The tool will read the content of the SD card (external or internal storage) up-to a predefined size (100Mb up-to 1Gb) and show resulting speed for various values of readahead (from 128Kb up-to 5Mb).

On a Nexus 4 running Android 4.2, 128Kb and 256Kb were between 20-50% slower, depending on files being read.
On a S10+ running Android 10 however, gain of increasing read-ahead is not so obvious.

I'd be very much interested in results from other devices running various version of Android.

You can get the tool here, and get support here.
Attached Thumbnails
Click image for larger version

Name:	Nexus4_1.png
Views:	48
Size:	122.4 KB
ID:	4995071   Click image for larger version

Name:	Nexus4_2.png
Views:	48
Size:	117.3 KB
ID:	4995073   Click image for larger version

Name:	Nexus4_3.png
Views:	48
Size:	121.8 KB
ID:	4995075   Click image for larger version

Name:	S10+_1.jpg
Views:	46
Size:	167.6 KB
ID:	4995085   Click image for larger version

Name:	S10+_2.jpg
Views:	46
Size:	233.6 KB
ID:	4995087   Click image for larger version

Name:	S10+_3.jpg
Views:	46
Size:	242.5 KB
ID:	4995089  
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes