Here I am providing a link for a modified version of the 20110721 rootfs.img. But before anything else, allow me to explain exactly what was modified and why. And also, I'm running FRX07 with the default kernel it came with and the newest rootfs, OC'd to 614.4MHz (although OC doesn't play much factor in this tweak)
During the portion of the boot cycle when it loads the rootfs, at some point the read_ahead_kb (cache on the SD card) is set to 2,048KB as default with the newest rootfs. For higher-end SD cards, this is a good, wholesome number to work with..
With me, I'm running on a 2GB class 2, and using the program SD Booster (free), I was able to switch the read_ahead_kb while running Android. I tried multiple values and noticed the best results with 256KB.
Before with the 2048KB setting, the boot animation would cease a few times for probably a good 6-7 seconds, was terribly laggy throughout, and ultimately, from my experience, the performance of Android was impacted negatively. The system would literally halt while performing basic operations such as opening the Settings menu... although not all the time, still pretty annoying :\
By making this change in the rootfs.img, I noticed that the boot animation was MUCH MUCH smoother. I did not get the aforementioned problem at all using this rootfs.img with my SD card. And I also noticed a nice decrease in boot time, PLUS a pretty hefty boost in performance and stability after the boot even more than when manually changing the value with SD Booster!
I know not all people are running on premium SD cards and that is pretty much the whole point of this thread: to provide people who DON'T have the best with something that could help with their performance.
And for the record, I'm no dev. I just know some bits and pieces and like to share my experiences.
Please post feedback if it helps you!! It makes me feel better lol
ALSO: Before I even thought to post this, I made sure I uninstalled SD Booster to make sure it didn't apply any settings on boot, rebooted the phone into Android, reinstalled SD Booster, and noticed that it was no longer set to 2,048KB as default doesn't hurt to double-check!!
Since you're talking about a 1-line change, it would seem to me to have been far more efficient just to post the single line you changed, rather than make people download a multi-megabyte rootfs img file all over again.
highlandsun said:
Since you're talking about a 1-line change, it would seem to me to have been far more efficient just to post the single line you changed, rather than make people download a multi-megabyte rootfs img file all over again.
Click to expand...
Click to collapse
Good point.. although most people like swapping rootfs.img's and making things easy, plus I already had the rootfs ready for myself.. I figured why not.
But you're right, it would be helpful to know either way, so this is exactly what I did. I opened the init file within the rootfs.img (after mounting in Ubuntu) and searched for "read_ahead_kb" and found it. At the front of the line read: "echo 2048". That's the command that enables the 2,048KB SD cache during boot (the rest of the line I assume is to apply that setting to the SD card? Not sure..). I changed that value to 256KB, making that: "echo 256". Saved the file, unmounted the rootfs, and voila.
maff1989 said:
Good point.. although most people like swapping rootfs.img's and making things easy, plus I already had the rootfs ready for myself.. I figured why not.
But you're right, it would be helpful to know either way, so this is exactly what I did. I opened the init file within the rootfs.img (after mounting in Ubuntu) and searched for "read_ahead_kb" and found it. At the front of the line read: "echo 2048". That's the command that enables the 2,048KB SD cache during boot (the rest of the line I assume is to apply that setting to the SD card? Not sure..). I changed that value to 256KB, making that: "echo 256". Saved the file, unmounted the rootfs, and voila.
Click to expand...
Click to collapse
Interesting. I don't think my card would be considered 'premium', but it is a class4 card.
I'll see if this change makes any difference. IIRC this value was bumped in the newest build to provide better performance, not worse! I guess that's the tradeoff - better performance for some, worse for others... oh well. Thanks for your work!
arrrghhh said:
Interesting. I don't think my card would be considered 'premium', but it is a class4 card.
I'll see if this change makes any difference. IIRC this value was bumped in the newest build to provide better performance, not worse! I guess that's the tradeoff - better performance for some, worse for others... oh well. Thanks for your work!
Click to expand...
Click to collapse
You're very welcome I know the 256kb setting may not work better for all.. but I think this setting is key to how well Android performs on different cards.
Also, I DID notice that OC'ing is much more stable using this setting for my SD.. currently running at 768MHz and minimal instabilities.
Sent from my MSM using XDA App
I appreciate you posting the process you used to figure out optimal settings. I'm toggling between sd tools and sd booster as we speak. I'm still trying different settings. If my settings are different, that'll give me an excuse to figure out that virtualbox build I started on a few months ago.
EDIT: hmmm, I'm not sure sd tools is going to be a useful bench tool. 2 different runs on the same settings vary pretty wildly. I think the meter animations might be interfering with the testing. How did you decide which setting performed best while using sd booster? Were you just going with what felt best?
fortunz said:
I appreciate you posting the process you used to figure out optimal settings. I'm toggling between sd tools and sd booster as we speak. I'm still trying different settings. If my settings are different, that'll give me an excuse to figure out that virtualbox build I started on a few months ago.
EDIT: hmmm, I'm not sure sd tools is going to be a useful bench tool. 2 different runs on the same settings vary pretty wildly. I think the meter animations might be interfering with the testing. How did you decide which setting performed best while using sd booster? Were you just going with what felt best?
Click to expand...
Click to collapse
Personally, I never benchmarked my results.. I would change the kb setting in SD Booster to different values and resume normal operation of the phone (opening programs, checking for any abnormal "halts" during opening/closing animations and general program operation).
Basically, you're right; I found the best setting for my card based on trial-and-error and what felt right, then applied that setting in the rootfs to further increase performance over applying this setting AFTER boot.
Whichever setting feels right to you will most likely yield the best results.
Sent from my MSM using XDA App
maff1989 said:
Good point.. although most people like swapping rootfs.img's and making things easy, plus I already had the rootfs ready for myself.. I figured why not.
But you're right, it would be helpful to know either way, so this is exactly what I did. I opened the init file within the rootfs.img (after mounting in Ubuntu) and searched for "read_ahead_kb" and found it. At the front of the line read: "echo 2048". That's the command that enables the 2,048KB SD cache during boot (the rest of the line I assume is to apply that setting to the SD card? Not sure..). I changed that value to 256KB, making that: "echo 256". Saved the file, unmounted the rootfs, and voila.
Click to expand...
Click to collapse
Should I use DroidExplorer after booting the phone and then should I be looking for a file simply called "init" with no extension - or how do I do it ? It's just that I now see that a new rootfs 20110724 has just been released and since I'm sure it won't be the last, I'd like to know how best to edit these myself
C
championc said:
Should I use DroidExplorer after booting the phone and then should I be looking for a file simply called "init" with no extension - or how do I do it ? It's just that I now see that a new rootfs 20110724 has just been released and since I'm sure it won't be the last, I'd like to know how best to edit these myself
C
Click to expand...
Click to collapse
Yes, the init file will be located in the "/" directory (where you find the /system and /data folders), and in that file, seach for "read_ahead_kb", and once you find that line, go to the bbeginning of that same line and change "echo 2048" to whichever value works best with your SD card.
Personally, I would use a program on the phone such as Root Explorer to modify the file, save, and reboot to have the effects instantly. That would simulate the same process I used to modify the rootfs in Ubuntu.
Sent from my MSM using XDA App
Gee, why all this complicated workaround for something easily done in one line inside froyo.user.conf...
echo "256" > /sys/devices/.....
-- Starfox
Starfox said:
Gee, why all this complicated workaround for something easily done in one line inside froyo.user.conf...
echo "256" > /sys/devices/.....
-- Starfox
Click to expand...
Click to collapse
Um, it's not anymore complicated... Although my wording might have made it seem that way. The only difference was mounting the rootfs.img and changing the value in the init instead of the froyo.user.conf.
maff1989 said:
Um, it's not anymore complicated... Although my wording might have made it seem that way. The only difference was mounting the rootfs.img and changing the value in the init instead of the froyo.user.conf.
Click to expand...
Click to collapse
Well... the user.conf method probably is easier, considering you won't have to change it with any rootfs updates - you can swap rootfs', so long as that entry is in the user.conf file it will always get reapplied.
arrrghhh said:
Well... the user.conf method probably is easier, considering you won't have to change it with any rootfs updates - you can swap rootfs', so long as that entry is in the user.conf file it will always get reapplied.
Click to expand...
Click to collapse
Yeah, that's true, since you put it that way lol. I was simply looking for the most direct way to apply the change, and the modding the rootfs seemed like the logical choice. Tbh I didn't know the user.conf was that significant.. besides applying some user-based settings and whatnot.
Boy I have a LOT to learn...
maff1989 said:
Yeah, that's true, since you put it that way lol. I was simply looking for the most direct way to apply the change, and the modding the rootfs seemed like the logical choice. Tbh I didn't know the user.conf was that significant.. besides applying some user-based settings and whatnot.
Boy I have a LOT to learn...
Click to expand...
Click to collapse
You and me both! I still have quite a bit to learn about how Android has been pieced together on our phones. Doesn't help that I don't really know jack about Android itself .
The user.conf file is quite powerful, assuming you don't need stuff applied too early in the boot process...
arrrghhh said:
You and me both! I still have quite a bit to learn about how Android has been pieced together on our phones. Doesn't help that I don't really know jack about Android itself .
The user.conf file is quite powerful, assuming you don't need stuff applied too early in the boot process...
Click to expand...
Click to collapse
For me, Android as an operating system is easy to understand, since it operates similarly to any computer system. But the fine details like how the rootfs, initrd.gz, kernel, and (most recently) the user.conf work puzzles me like no other. +1 for a Dev Learning Thread!
And yeah, the initrd.gz is what is loaded first, and to my knowledge it's that portion of the boot process that handles the Apps2Ext2/SD function... Fun little tidbit of info
You just need to study init (the file) to find out where everything is located, then adjust what you put into froyo.user.conf. Anything that is done before userinit.sh parses *.user.conf can be manipulated directly, anything after you need to get creative with sed or similar.
Initrd is the INITial Ram Disk. Basically, the kernel when loaded does not have enough to load the whole root/etc. so the initrd contains enough tools to get the kernel to recognize where the rootfs is and load it, then pivotroots with the real root then exec init.
App2sd has nothing to do with initrd. /sdcard/.android_secure, if you look in a real Android handset, is a world-unreadable/inaccessible directory. If you look closer, you notice it's been bind-mounted with those permission to "hide" the content. If you umount it, you have files named *.asec, which is a encrypted (to my knowledge) mini-fs containing the files for each program moved to SD. When Android boots it loopmounts each file to a dir in /mnt/asec or something. I don't think XDAndroid has the necessary stuff that goes through .android_secure yet.
-- Starfox
Starfox said:
You just need to study init (the file) to find out where everything is located, then adjust what you put into froyo.user.conf. Anything that is done before userinit.sh parses *.user.conf can be manipulated directly, anything after you need to get creative with sed or similar.
Initrd is the INITial Ram Disk. Basically, the kernel when loaded does not have enough to load the whole root/etc. so the initrd contains enough tools to get the kernel to recognize where the rootfs is and load it, then pivotroots with the real root then exec init.
App2sd has nothing to do with initrd. /sdcard/.android_secure, if you look in a real Android handset, is a world-unreadable/inaccessible directory. If you look closer, you notice it's been bind-mounted with those permission to "hide" the content. If you umount it, you have files named *.asec, which is a encrypted (to my knowledge) mini-fs containing the files for each program moved to SD. When Android boots it loopmounts each file to a dir in /mnt/asec or something. I don't think XDAndroid has the necessary stuff that goes through .android_secure yet.
-- Starfox
Click to expand...
Click to collapse
Thank you for the information, it's very enlightening
I mentioned Apps2SD because I owned an HD2 and was able to modify the initrd.gz to remove the Apps2SD functionality in a NAND Android ROM.. But thank you again for helping clarify any misunderstandings.
Also, if you have any links/bookmarks to online resources regarding these topics, I'd love for you to share cuz I'd hate to ask questions that could be answered with the right research. Plus, I'm sure you have better things to do with your time than to answer all the questions I have lol
Found this link here on XDA:
Increase Read Cache
I'm using SD Tools and SD Booster to change the cache and test the speed.
Got a class 6 card. Still playing around
großa said:
Found this link here on XDA:
Increase Read Cache
I'm using SD Tools and SD Booster to change the cache and test the speed.
Got a class 6 card. Still playing around
Click to expand...
Click to collapse
I have seen that link a while back; never could get that method to work, though I'm not saying that it doesn't.
From my experience, the difference between using SD Booster and applying the change to the rootfs/user.conf is that the read_ahead_kb, during boot, will impact the remainder of the boot process and furthermore, impact overall performance. That's why, for me, SD Booster simply wasn't cutting it. Although, it was VERY useful in helping me determine which value to place in the rootfs to get the best results.
I've been trying to find a more reliable objective benching tool since sdtools results seem almost random for me. That thread above suggests timing the opening of the gallery, but when I do, not all of the lag appears related to reading the contents of the card -- some of it seems tied up in animations. Anyone have any other ideas?
I actually might try overclocking temporarily if I can't find another card speed bench that less animated. I think the problem with me and sdtools is related to speedometer graphics. It hangs for 15-45 seconds at the beginning of the test while the needle makes its way painfully slowly to the first burst of speed read before continuing the test. Running multiple tests on 2048, 1024, 512 and 256 as set in sd booster, there was almost as much variation at each setting as there was between all the settings.
I found this trick in S6 forums. Thanks to @mikeyinid
Paste:
Explanation: (From @mikeyinid )
Here is a quick rundown on how this came about, and what we actually know.
Since I purchased the S6 on release day, I've been messing with certain things, as you can see from the ROM I posted, Looper(shameless plug). Debloating Samsung apps really helped with battery life and I was pretty happy with the results. But like so many other people, I didn't understand why my S6 killed apps so aggressively. Initially I thought it might be the memory leak we all know so much about in 5.0. So, I did a little research and found the patch for that. While it did help keep the device stable over time, apps were still being killed with no prejudice. All this time I noticed really useless services running in the background, often stuff I'd never even opened. I studied LMK and started messing with those settings. After a month of trying everything I could find documented, I was ready to give up. Yesterday I was looking through the services.jar smali for the 37,875th time and realized the DHA referenced in there has to have something to do with memory management. I kept overlooking it because I hadn't seen mention of it anywhere else. I am no smali guru, as some of you know. But it was pretty obvious DHA was influencing memory management to some extent. Samsung, although leaving us in the dark on this, was kind enough to give us props to set the values for DHA. I pulled a few that seemed relevant, added them to my build.prop, and what do you know. For the first time in almost two months of tinkering, I saw an improvement in the way my device was managing memory.
The thing everyone needs to understand; I have no clue what DHA is. It overrides every aspect of Googles LMK and seems to do so in a way that makes more sense. I'm sure someone with more knowledge than myself will be able to tune this to the point the S6 will be the multi-tasking champ. There are several other props in the smali that are probably useful. I will try to get them all with their default values posted today. This has been pretty exciting for me, I spent way to much time trying to figure out the issue to not make some sort of progress. I hope you guys enjoy the tweaks, and I hope it helps sway those of you on the fence about keeping this device to stay. It's only gonna get better
Instructions:
First find your build.prop. This is located in /system. to get to /system you need to go to the root directory using a file explorer and then go to the system folder. The build.prop will be in there. You can also use and app such as build.prop tweaker but its a bit harder (imo)
In your build.prop scroll to the very bottom and paste this in:
(values in my build.prop Note 3 Neo, may be others values work better but for me are awesome)
ro.config.dha_cached_max=30
ro.config.dha_cached_min=14
ro.config.dha_empty_init=36
ro.config.dha_empty_max=12
ro.config.dha_empty_min=8
ro.config.dha_th_rate=1.0
ro.config.dha_lmk_scale=0.878
Delete duplicate lines if you find.
Other thing. With Kernel Adiutor in LMK section select "very agressive" and apply on reboot.
Finally reboot your device.
Enviado desde mi SM-N7505 usando Tapatalk 2
other values to compare how it works, only four lines to add to build.prop:
ro.config.dha_cached_max=15
ro.config.dha_empty_max=30
ro.config.dha_lmk_scale=0.600
ro.config.dha_th_rate=1.4
Note, activate too "very agressive" mode in LMK (Kernel Adiutor)
everything works without freezing, bootloop?
Folks;
unsure whether this is the best forum for my question - apologies if this is completely off here. I want to get photo management on my device a bit improved (thousands of images, several different camera and processing apps each of them storing to different folders). I am looking for an automatism, app, ... that does more or less the following:
* Run either on demand (which is ok for me) or periodically at the end of each month.
* Create a monthly image folder <YEAR>_<MONTH> in some configurable place, if not already existing. external SD would be best for this, but is not strictly required.
* Find all images taken (or processed) in the current month in a bunch of configurable folders (DCIM, Pictures, ...).
* Move all these findings over to the <YEAR>_<MONTH> backup folder.
I placed a similar question (http://forum.xda-developers.com/u/t...ate-monthly-image-folder-external-sd-t3420418) in the Tasker forum but actually I am completely unsure whether I want/need Tasker, Automate or something like this to get this job done. Maybe some sync application, a "better" file manager, an image gallery, ... also can do that job. Important, however, would be for me that manual effort to get this done is pretty limited - I do not want to manually select and move a bunch of files but essentially an "icon", an app, ... that can be launched and does just that.
TIA and all the best,
Kristian
For whatever it's worth, just to close this: After playing around with various solutions, the most comfortable approach I found was creating an Automate (http://llamalab.com/automate/community/) flow that manages to do exactly this. Ask me if interested.
I have a dual boot Android 5.1/Win 10 tablet (the Onda oBook10) that I recently managed to acquire root on (for any owners of this device that would like to know how, I'll be posting a guide soon). This thing has 4 gigs of RAM, but starts kicking apps out as soon as 1 GB is occupied. I've tried setting minfree using both Kernel Adiutor and by echoing manually to /sys/module/lowmemorykiller/parameters/minfree, but neither has any effect. I know that this change doesn't persist across reboots on any Android, but in this case, it has no effect even on the current session. What's even stranger, going by the default values that have been set, there shouldn't be any issues at all - it's actually less aggressive than most other devices I've seen. The values are:
Code:
13107,16384,19660,22937,26214,32768
According to Kernel Adiutor, that translates to (in MB):
Code:
51,64,76,89,102,128
Yet, running apps shows 2.8 to 3.1 GB free constantly, even though apps are reloading.
Does anyone know what might be causing this? It's an x86 device, in case that's relevant. I have access to the boot image (in case it's some kind of kernel flag), and can unpack to ramdisk and zImage, but I have no experience with kernels, and have no idea where to even begin looking; if someone could point me in the right direction, that would be awesome.
Thanks,
SirVer