[Q] Sysctl what and how ? - XPERIA X10 Q&A, Help & Troubleshooting

hi evryone i've bin looking around for a while now and i can't seem to find the exact thing/explenation i am looking for.
i would like to know what the following are used for.
simply a more value means this
less value means that
if its possible what i understand from it for now is
Min Free KBytes(obvious is suppose)
Dirty Ratio(controls the delay of the kernel writes to data why is this important?so i can control how long it takes for him to flush his memory ?)
Dirty Background Ratio
VFS Cache Pressure(smaller value is bigger cache wich in the end could bite me in the ass ??)
Oom Allocating Task(instead of scanning what to kill it kills whatever made it exceed the memory??)
all i could find on google is people and there prefered settings.
wich could be amazing but aslong as i dont SEE a difference seeing my phone runs smooth to begin with
its rather hard to find out what it does
ty in advance
edited for overview

Related

[Q] UrukDroid (and possible other mod OS'es): understanding CompCache?

I am having trouble in understanding if and how best to use Compcache and/or Swap.
I see that the default config of UD not is CompCache AND Swap on. But I see no benefit. The memory never seems to be used (also it feels slower).
Even if I use CompCache 64Mb with swapiness at 80, if I check stats there is never more uses than about 32mb. But Android does go ahead and close programs in the mean time. Stuff does not keep running if I go to another program, it has to be restarted if I switch back.
So why does the system not use all 'RAM' available to it? Should swapiness be increased even more?
I wonder if your minfree settings may be keeping your compcache swap from being fully utilized. What does the output of 'cat /proc/swaps' in a terminal look like? What are your minfree settings?
I don't know if I understand the compcache thing fully, and I'm no Android expert....
From what I read from the net, both compcache and swap memory only swaps kernal memory, so it does not mean every bit of compcache will be used, as kernal only uses a limit amount of memory. If a certain program uses a lot of memory outside kernal, then other programs will still be closed to make room for it. In short, compcache is just an alternative solution, it's never a real solution for lack of ram.
For me, I actually experimented with setting 192MB compcache and swapiness of 100. It seems to work well for me, and the most I've seen it used is only about 30MB.
Thanks guys, I'll look at both things - minfree and setting swapiness to 100 - and report back!
As to minfree, I saw other threads that seemed to point in this direction as well, but maybe this is something different.
The other threads were talking about that the system/kernel would not get notified of the "additional free RAM" offered by the CompCache, so that it would still kill programs is there would still be CompCache (but not much real free RAM) available...?
[EDIT] this may help us to some answers, or part of, reading now myself...

Patched libsqlite.so to disable sync and improve SQLite performance

Based on this thread:
http://forum.xda-developers.com/showthread.php?t=1595531
and this one:
http://forum.xda-developers.com/showthread.php?t=903507
After quite some reading and messing about it worked...
I have patched sqlite3.c from CM9 ICS source and recompiled CM9 (for nexus, the tutorial used that one... but files seem interchangable).
!!!WARNING!!!
!!!Use this at your own risk! I will not be responsible for any messed up primes, errors and/or loss of data!!!
This can mess up your prime! Only do this if you have a working CWM backup and can restore that backup from recovery! Root is required at this time to replace the files...
I have no idea what this does with data integrity, if you value your data extremely it might be wise not to try this!
!!!WARNING!!!
*RISK*
As explained by Hobbesian in this post: http://forum.xda-developers.com/showpost.php?p=27121811&postcount=39
Fsync off means that SQLite is unbound by the need to check that data has been written to disk successfully, it also means the operating system can freely re-order the writes before they are comitted to flash memory, which in the event of a hardlock will very likely result in database corruption, of the unrecoverable sort.
Fsync in itself is often used -deliberately- to incur an I/O buffer, so whilst it might seem like a great idea to turn it off, what you're essentially doing is risking the CPU going faster than the device controller can write to memory. This is bad. I cannot begin to imagine how many klaxons would go off if you're working on something remotely important and use this patch.
*RISK*
I hereby attach the zip containing the libsqlite.so and libsqlite_jni.so.
1. Copy the files (using root explorer for example) to the /system/lib folder, replacing the original files. (Mount that folder as RW if necessary).
2. Set permissions to the same as the other files, rw-r--r--.
3. Reboot.
If something went wrong your prime will not boot but will be stuck at the booting screen, in that case recover to a working backup using CWM.
SQLite benchmark went from 100+ secs to 20-25 seconds. Quadrant IO bench improved as well.
Have yet to decide on realtime performance but I actually believe the internal memory is pretty mediocre, physically... So this only helps partially in that case.
It's fun to play with sync settings but not if you value your data. I would strongly advise against it except for testing and benchmark purposes...
Thanks, but Iḿ awarre of possible consequences... But I believe the conclusion in earlier versions was that, even though there are indeed risks, they aren't as huge as you'd might expect. Mainly with unexpected reboots or shutting down the risk is big(ger).
But even if itś just for testing/benching... I would still very much like to see the results.
Btw, it should be ARM v7 even... that is the proper instruction set. Updated starting post.
Ugh, got it to build for arm-v7a but of course it looks (completely) different from the module with the prime. Structure the same, but compiled different enough. So thought I'd compule the library and install it on the prime but that resulted in the prime not booting...
Hmmm
I'd love to help, but I have zero knowledge in anything SQLite...
I wish you good luck!
I think everyone is hoping that the slow random write speeds are purely software related. And it makes sense that they are. The SQLite benchmarking thread is giving a lot of details on what is making our performance so sluggish, but not why.
Next step, compile complete CM9 source (hopefully including libsql src ) so I can use that as a base...
Copying the libsqlite.so and libsqlite-jni.so from an AOKP rom worked fine, so perhaps this is a (not the easiest) way to get things to work.
And ah well, otherwise I learnt how to compile a rom
xTRICKYxx said:
I'd love to help, but I have zero knowledge in anything SQLite...
I wish you good luck!
I think everyone is hoping that the slow random write speeds are purely software related. And it makes sense that they are. The SQLite benchmarking thread is giving a lot of details on what is making our performance so sluggish, but not why.
Click to expand...
Click to collapse
Same here, thanks for taking time out to tinker with our primes...........hmm, im not intirelly sure if i should refrase that???
GD LUCK
dagrim1 said:
Next step, compile complete CM9 source (hopefully including libsql src ) so I can use that as a base...
Copying the libsqlite.so and libsqlite-jni.so from an AOKP rom worked fine, so perhaps this is a (not the easiest) way to get things to work.
And ah well, otherwise I learnt how to compile a rom
Click to expand...
Click to collapse
Are you actually changing rom code to remove fsync?
hairdewx said:
Are you actually changing rom code to remove fsync?
Click to expand...
Click to collapse
Ehm, basically... Not rom code itself but one of the libraries in the rom (for which I hope the code is in there as well).
Background info:
http://forum.xda-developers.com/showthread.php?t=1000899
Android phones as the underlying database using sqlite3. sqlite3 writes efficiency is very low, because the sync feature turned on by default, and fsync() must be performed after each insertion, the resulting system efficiency is low, and the disk life is reduced.
I try to disable sync feature by default in exchange for greater IO performance and reduce disk consumption. While doing so may result in data integrity problems, but I still like to use it because most of the sqlite insert action can be completed within a few seconds, not too much to consider issues such as sudden power-down.
After modified, the time of insert 2000 records to sqlite3 db, from 1m11s reduce to 2s.
-----------------------------
With Android applications, the database operation is non-persistent, normal step in app is:
1.open db
2.do read/write
3.close db
with step3, the data in cache will be flush to disk. so user will not notice any sudden lag, always smooth.
With SYNC-ON, the db operation like this:
1.open db
2.1. write a record/do a transcation
2.2. fsync()
2.3. write a record/do a transcation
2.4. fsync()
.....
3.close db/fsync()
with SYNC-OFF, operation like this:
1.open db
2.1 write a record/do a transcation
2.2 write a record/do a transcation
....
3. close db/fsync()
So, no-sync can significantly save IO time.
Click to expand...
Click to collapse
Patch for libsqlite.c:
http://forum.xda-developers.com/showpost.php?p=12695464&postcount=1966
Code:
diff -urNp external/sqlite/dist.origin//sqlite3.c external/sqlite/dist//sqlite3.c
--- external/sqlite/dist.origin//sqlite3.c 2011-01-07 15:26:32.000000000 +0800
+++ external/sqlite/dist//sqlite3.c 2011-01-07 15:27:55.000000000 +0800
@@ -34761,7 +34761,7 @@ SQLITE_PRIVATE int sqlite3PagerOpen(
pPager->readOnly = (u8)readOnly;
/* pPager->needSync = 0; */
assert( useJournal || pPager->tempFile );
- pPager->noSync = pPager->tempFile;
+ pPager->noSync = 1;
pPager->fullSync = pPager->noSync ?0:1;
pPager->sync_flags = SQLITE_SYNC_NORMAL;
/* pPager->pFirst = 0; */
@@ -65838,7 +65838,7 @@ static void attachFunc(
sqlite3PagerLockingMode(pPager, db->dfltLockMode);
sqlite3PagerJournalMode(pPager, db->dfltJournalMode);
}
- aNew->safety_level = 3;
+ aNew->safety_level = 1;
aNew->zName = sqlite3DbStrDup(db, zName);
if( rc==SQLITE_OK && aNew->zName==0 ){
rc = SQLITE_NOMEM;
@@ -97124,7 +97124,7 @@ static int openDatabase(
** database it is 'NONE'. This matches the pager layer defaults.
*/
db->aDb[0].zName = "main";
- db->aDb[0].safety_level = 3;
+ db->aDb[0].safety_level = 1;
db->aDb[1].zName = "temp";
db->aDb[1].safety_level = 1;
So the basic idea is to limit IO-interaction by disabling fsync.
Interesting, I figured it would have been in one of the kernel modules.
Ok, I have been able to compile the CM9 source (for the galaxy nexus, because the tutorial was for that one) including the sqlite source...
First test was now 36,6 secs which is pretty nice, have to check for other issues (and will compile for TF201 if I can soon). The semi patch caused a number of force closes so we'll have to see how this one goes.
But at least happy I was able to compile
Wow ... thanks for posting this ... I've edited the sqlite source and compiled the binary for AOKP B38 below are my setup details and test results. So far everything is stable, no FCs in the past 45 min and things are much faster. I have no idea whats up with Antutu's SD Card reads, that's outrageously high lol ... Can't say I trust that ;o) . Otherwise great hack. I wouldn't recommend running this if you have a need for solid data stability, I haven't seen anything yet, but ending all those syncs may cause problems down the road, I don't know. Since I flash regularly I don't really mind it, loving the speed! Also found some other sqlite optimization tips( Cache size and some others ) I may try to add in after I run it for a day as is and see how stability is. Again, thanks to the OP, great find!( so far )
Code:
Device: Transformer Prime(TF201)
ROM: AOKP B38
Kernel: Motleys running at 1.8 set to performance governer for testing
Tests: ( All tests done Run 1 after fresh boot, Run 2 immediatly after, all set to performance governer )
Couldn't get the damn formating to look right in the post ... check the image for results.
RubenRybnik said:
Wow ... thanks for posting this ... I've edited the sqlite source and compiled the binary for AOKP B38 below are my setup details and test results. So far everything is stable, no FCs in the past 45 min and things are much faster. I have no idea whats up with Antutu's SD Card reads, that's outrageously high lol ... Can't say I trust that ;o) . Otherwise great hack. I wouldn't recommend running this if you have a need for solid data stability, I haven't seen anything yet, but ending all those syncs may cause problems down the road, I don't know. Since I flash regularly I don't really mind it, loving the speed! Also found some other sqlite optimization tips( Cache size and some others ) I may try to add in after I run it for a day as is and see how stability is. Again, thanks to the OP, great find!( so far )
Code:
Device: Transformer Prime(TF201)
ROM: AOKP B38
Kernel: Motleys running at 1.8 set to performance governer for testing
Tests: ( All tests done Run 1 after fresh boot, Run 2 immediatly after, all set to performance governer )
Couldn't get the damn formating to look right in the post ... check the image for results.
Click to expand...
Click to collapse
What about actual use performance? Is web browsing lag gone? What about switching apps?
I'm a little hesitant about the data stability... with my luck I'll have rock solid stability until the ONE TIME I actually need it and lose important data
Updated main post...
This should be in dev section?
Looks promising, thanks OP.
Sounds very promising. Rooted people, start testing!
sweet. going to try it tonight!
---------- Post added at 01:33 PM ---------- Previous post was at 01:13 PM ----------
RubenRybnik said:
Wow ... thanks for posting this ... I've edited the sqlite source and compiled the binary for AOKP B38 below are my setup details and test results. So far everything is stable, no FCs in the past 45 min and things are much faster. I have no idea whats up with Antutu's SD Card reads, that's outrageously high lol ... Can't say I trust that ;o) . Otherwise great hack. I wouldn't recommend running this if you have a need for solid data stability, I haven't seen anything yet, but ending all those syncs may cause problems down the road, I don't know. Since I flash regularly I don't really mind it, loving the speed! Also found some other sqlite optimization tips( Cache size and some others ) I may try to add in after I run it for a day as is and see how stability is. Again, thanks to the OP, great find!( so far )
Click to expand...
Click to collapse
Regarding your screenshot, the 1k inserts: After the SQL Patch those scores are on par with the other devices where we've seen benchmarks from (less than 1 second, which is literally 100 times better.. )
I don't believe in coincidence
Can it be that on those devices FSync is allready disabled, or bypassed only in some cases?
Anyhow i am realy curious if this makes stuff feel better
Tempie007 said:
Regarding your screenshot, the 1k inserts: After the SQL Patch those scores are on par with the other devices where we've seen benchmarks from (less than 1 second, which is literally 100 times better.. )
I don't believe in coincidence
Can it be that on those devices FSync is allready disabled, or bypassed only in some cases?
Anyhow i am realy curious if this makes stuff feel better
Click to expand...
Click to collapse
Posted this in the TFP's AOKP thread in that 'other' forum:
I'm seeing some great results personally. Chrome on prime seems really responsive, apps launch pretty much instantly, haven't seen a desktop redraw on Nova the whole time. I have an image folder with about 300 wallpaper images, opening that in quickpic in the past has been pretty slow( several seconds ), now that is almost instantly done, all thumbnails before I blink lol.
Now I'm not saying this is all the sql patch I did at all, unfortunately I didn't put much time into using Montleys new kernel in a 'real world' case, I only benchmarked with his kernel then applied sql patch and benchemarked again( still using his kernel ). So perhaps I'll flash back tonight just to see if I can gauge how much the patch vs kernel is doing.( Thanks again Motley! ).
As for side effects, I installed Chrome last night so I could test, had about a 2 second freeze at the end of it installing, but came back and was fine after. Haven't seen any other freezes. I did 'loose' wifi for about 20 min last night. I was connected to the wifi the entire time, but even a reboot and net wouldn't work on the Prime, not sure what happened, or if it's related, but seemed to have 'fixed' itself after 20 min last night.
Click to expand...
Click to collapse
Tempie007 said:
sweet. going to try it tonight!
---------- Post added at 01:33 PM ---------- Previous post was at 01:13 PM ----------
Regarding your screenshot, the 1k inserts: After the SQL Patch those scores are on par with the other devices where we've seen benchmarks from (less than 1 second, which is literally 100 times better.. )
I don't believe in coincidence
Can it be that on those devices FSync is allready disabled, or bypassed only in some cases?
Anyhow i am realy curious if this makes stuff feel better
Click to expand...
Click to collapse
If it is, it is not done in the library itself...
I also tried the libsqlite files from the SGS3 for example and copied them to the prime, but that didn't help much... So if fsync is handled differently on those devices it is done in a different place.
This is just a workaround for (part of) the problem... The real issue is elsewhere. I mean, the CM9/AOKP/AOSP roms use the same source for the differnt devices yet the issues are not the same on all of them.
So somewhere in the kernel code? Or another level, the controller for example. As the HTC One X performs decent it seems that it's not (JUST) the tegra3 but some of the other components.
Ah well, maybe tonight I can try the full wipe and reinstall and see if that helps anything.
Booting time doesn;t improve with this mod, titanium restores improve a bit but nothing extreme (20-25% faster is my guess) so there IS more going on. My guess is the used memory is at least part of the problem.
Some SD benchmarking indicating the memory used isn't the best one :/ (Done with the 'Device Performance' benchmarking app)
Asus TF201:
[email protected]/mnt/sdcard (=internal)
Max Write: 14,4
Mean Write: 12,1
Min Write: 9,4
Max Read: 28,8
Mean Read: 23,2
Min Read: 14,9
[email protected]/Removable/MicroSd (=external)
Max Write: 14,7
Mean Write: 11,4
Min Write: 9,9
Max Read: 14,6
Mean Read: 12,7
Min Read: 9,0
SGS3:
[email protected]/mnt/sdcard (=internal)
Max Write: 26,7
Mean Write: 25,3
Min Write: 23,9
Max Read: 43,8
Mean Read: 42,2
Min Read: 39,4
[email protected]/mnt/extSdCard (=external)
Max Write: 10,6
Mean Write: 10,0
Min Write: 9,6
Max Read: 13,8
Mean Read: 10,6
Min Read: 6,2
Is it possible to make an intelligent fsync where it basically syncs after some clock time after the last db write or inserts an fsync with a high count of writes?

[Q] Trying to understand heap size and memory issues

I attempted to find an answer to this question but was unsuccessful. I'm not sure if my understanding of the Dalvik max heap size is incorrect or if there is some other aspect of memory management I am not understanding. I'm basically trying to get an understanding of how memory is used in Android.
I am looking at a fairly large application that is ran through an emulator. I set Max VM application heap size to 24MB in the AVD. I then run the application and run procrank on it. It shows the application is using about 50MB. How does this correspond to heap size? Why is the application showing 50MB when the max heap size is only 24MB? After messing around with the application I see memory jump to over 100MB. This seems terribly high to me but I don't know enough to say definitively.
Also, if I run MAT on it I am getting a totally different thing. I don't really understand what data is coming from MAT. It is showing a total of 3.4MB with most of it unused. What does this mean?
I've tried to read as much information as I can about memory usage but I think I'm just not quite understanding it. Any explanations or links would be very much appreciated.
Thank you in advance.

[HOW-TO] ASUS system boost - root required - v0.4 UPDATE!

Hello, last two days I thought about I/O performance of great Asus Transformer Prime.
It is actually PDA so it means that device is not in the real power off state so much.
It can be used for ANY kernel and ANY rom!
Works with ANY ASUS TRANSFORMER MODEL!!!!!!!!!!!!!!!!!!!!!
Sooo let's tweak it for better performance!
We will reduce write times to SSD drive, no more hangups, ARNs etc.
I am using it on my own prime for one day and I have no delays at all.
For this test I need huge amount of volunteers to tune numbers in the script.
This change is only for actual session
If you want to save it after reboot use SManager for script autorun.
Here is script, run like. su
So download script on sdcard to root of sdcard, unzip and run:
Code:
su
cd /sdcard/
sh tune.sh
It is safe and it will not harm your system or break OTA update
The worst scenario is softresetting your device after
hang up (but it should be ok).
PLEASE I NEED RESPONSES FROM YOU!!!!
+ Faster system
+ less hangups (none on my Prime)
+ You don't have to flash new kernel
+ It is for actual session only, after reboot you have to run script again
+ Better battery life!
+ Longer life for internal SSD drive!
- If you reset your prime you can loose some of your datas
- If your system hangs you can loose some of your datas
- It is for actual session only, after reboot you have to run script again
EDIT: :::::::::::::::::: Ok version 0.2 is out. ::::::::::::::::::
With previous values I had problem with gmail.
With little tweaking I have no issues now and there is ALMOST no drop of permormance compared to version 0.1.
Changelog:
Code:
changed value for dirty_ratio from 90 to 70
changed value for dirty_background_ratio from 70 to 50
If you haven't gmail issues you don't have to install version 0.2
Nvm it seems that gmail issue had nothing to do with these changes
EDIT: 25.6.2012
Tune script is included here:
http://forum.xda-developers.com/showpost.php?p=27862975&postcount=149
:::::::::::::::::: EDIT 2: 26.6.2012 New version out v0.3 ::::::::::::::::::
+ tweak for battery (audio is suspended earlier when it is not used
+ some tweaks to cfs scheduler should be more responsive
Let me know your experiences with this version!!
::::::::::::::::::8.7. 2012 NEW VERSION OUT! v0.4 ::::::::::::::::::
Some of ideas taken from here ! http://forum.xda-developers.com/showthread.php?t=1205259
Optimalized for Prime
+ Added three types of scripts
+ 1st script = tune.v0.4.sh.zip = safe optimalization = only safe tweaks which will speed up IO operations a little bit
+ 2nd script = tune.v0.4.drive.sh.zip = drive optimalization = same like 1st script + optimalizations for internal ssd drive
+ 3rd script = tune.v0.4.max.sh.zip = heavy performance mode = 1st + 2nd script + "old" checked by users tweaks with background ratio, swapiness etc. + io mount tweaks + kernel tweaks + internet tweaks = max. perform. (for best turn sio TOO!!)
+ Longer life for internal SSD drive! Because noatime,noadatetime = less writes
- Somebody reported battery drain, so these relative functions were removed
Please for correct testing remove ATP application and run this script with SManager or manually (if you won't uninstall ATP it will change values...) If you don't want to remove ATP you have to wait for new developer of ATP when he will add these version of scripts to ATP !!!!!!!!!
If you have some problems after this script PLEASE try to remove ATP first, it seems that on some devices it has problems with running this script.
ok i m running it right now.
what are the default values?
Sent from my Transformer Prime TF201 using Tapatalk 2
Sorry I dont remember. Reboot your prime and you will see defaults.
batoo said:
Hello, last two days I thought about I/O performance of great Asus Transformer Prime.
It is actually PDA so it means that device is not in the real power off state so much.
It can be used for ANY kernel and ANY rom!
Sooo let's tweak it for better performance!
We will reduce write times to SSD drive, no more hangups, ARNs etc.
I am using it on my own prime for one day and I have no delays at all.
For this test I need huge amount of volunteers to tune numbers in the script.
This change is only for actual session
If you want to save it after reboot use SManager for script autorun.
Here is script, run like. su
So download script on sdcard to root of sdcard, unzip and run:
Code:
su
cd /sdcard/
sh ratio.sh
It is safe and it will not harm your system or break OTA update
The worst scenario is softresetting your device after
hang up (but it should be ok).
PLEASE I NEED RESPONSES FROM YOU!!!!
+ Faster system
+ less hangups (none on my Prime)
+ You don't have to flash new kernel
+ It is for actual session only, after reboot you have to run script again
+ Better battery life!
- If you reset your prime you can loose some of your datas
- If your system hangs you can loose some of your datas
- It is for actual session only, after reboot you have to run script again
Click to expand...
Click to collapse
Tempie007 said:
ok i m running it right now.
what are the default values?
Sent from my Transformer Prime TF201 using Tapatalk 2
Click to expand...
Click to collapse
Hi, it will be interesting to see how this works. swappiness=0 will cause less swapping to disk (it will only happen when it needs to). Default for swappiness=60 in our Android and mainline Linux kernels. These settings here are aggressive in trying to reduce swap disk i/o, so it will be great to see if it succeeds and whether or not OOM errors occur when RAM is running short when using RAM hungry applications or doing extreme multi-tasking.
I have also been testing something at the vm level in the kernel that I found in the HTC OneX source. It is something the HTC engineers added that would actually set the default to swappiness=100, the complete other direction from what you are doing here. This theory is to clear out the stale RAM and open up the RAM for something more useful. While this may be counter-intuitive to I/O performance since swapping equates to more disk i/o, the code change also implements some changes to the block, fs, and mm portions of the kernel. Essentially, from what I can tell, it flags and handles disk operations (aka "bios") differently if they are involved in swap operations (going to or coming from swap). A "bio" is essentially a manifest of an ongoing I/O block device operation, what sectors and memory locations it contains etc. Once the RAM is freed up, I have also been increasing the Dalvik vm settings in the build.prop to allow for more RAM consumption. So far, this combination (at least for me so far) has really given me good UI performance and I haven't had to kill the browser often like I did before. I have yet to play with vm.dirty_ratio and vm.dirty_background_ratio, but I am wanting to do this as well to see what combination can work the best for us.
Anyhow, thought I would share. I think you are looking at some important things here with the tuning of virtual memory to see how they can affect disk performance and more importantly application fluidity.
Cheers
Hi
I'm using it for about two hours and I had one reboot when I opened File explorer (before this never happend to me on .28) Im using also IO Sio from Your other topic (it seems to be alright...everything seems to work smoother). On tune.sh I have better write to sd speed in antutu. Now I have 8 mb...before 2 mb. Thx for that.
_motley said:
Hi, it will be interesting to see how this works. swappiness=0 will cause less swapping to disk (it will only happen when it needs to). Default for swappiness=60 in our Android and mainline Linux kernels. These settings here are aggressive in trying to reduce swap disk i/o, so it will be great to see if it succeeds and whether or not OOM errors occur when RAM is running short when using RAM hungry applications or doing extreme multi-tasking.
I have also been testing something at the vm level in the kernel that I found in the HTC OneX source. It is something the HTC engineers added that would actually set the default to swappiness=100, the complete other direction from what you are doing here. This theory is to clear out the stale RAM and open up the RAM for something more useful. While this may be counter-intuitive to I/O performance since swapping equates to more disk i/o, the code change also implements some changes to the block, fs, and mm portions of the kernel. Essentially, from what I can tell, it flags and handles disk operations (aka "bios") differently if they are involved in swap operations (going to or coming from swap). A "bio" is essentially a manifest of an ongoing I/O block device operation, what sectors and memory locations it contains etc. Once the RAM is freed up, I have also been increasing the Dalvik vm settings in the build.prop to allow for more RAM consumption. So far, this combination (at least for me so far) has really given me good UI performance and I haven't had to kill the browser often like I did before. I have yet to play with vm.dirty_ratio and vm.dirty_background_ratio, but I am wanting to do this as well to see what combination can work the best for us.
Anyhow, thought I would share. I think you are looking at some important things here with the tuning of virtual memory to see how they can affect disk performance and more importantly application fluidity.
Cheers
Click to expand...
Click to collapse
Ice increased my dalvik vm also through build.prop. Like the heapsize, growth limit, startsize etc...how much can you increase those vm to where its still safe? On stock kernel.
What values are you running at? IM also using that dalvik jit mod.
demandarin said:
Ice increased my dalvik vm also through build.prop. Like the heapsize, growth limit, startsize etc...how much can you increase those vm to where its still safe? On stock kernel.
What values are you running at? IM also using that dalvik jit mod.
Click to expand...
Click to collapse
Not sure how much room there is since I have only tweaked on the prime recently. I am running 8m, 64m, and 256m now. One of my other tabs used higher dalvik settings like this on the HC stock ROM (GT 8.9 or Iconia A500 can't remember). There are so many parameters to take into account for any given test etc., as they say "you never step into the same river twice" LOL.
I have posted my latest alpha kernel with the aforementioned changes. It will be interesting to see if folks like it or not. It is working great for me thus far.
Guys pls no offtopic and chat.
Ill try this new tweak once I get off work.
my first problem. cmclient has stopped.
first time I have seen this in weeks and it comes after 45 min of this tweak.
However it may be related to the fact that I have not used the default browser in weeks.
whycali said:
my first problem. cmclient has stopped.
first time I have seen this in weeks and it comes after 45 min of this tweak.
However it may be related to the fact that I have not used the default browser in weeks.
Click to expand...
Click to collapse
a reboot should clear it. did you enter in commands exactly like listed in op? it tells me file not found. when i unzipped the file, it gives me a tune.sh txt file or whatever. in the commands, is it supposed to be "tune.sh" instead of "ratio.sh"? i see i can just click the file and execute the file like that, bypassing the need to enter in commands. same like with overclock files. i could just execute them manually instead of using an overclock app.
have you noticed any other issues? what benefits have you noticed so far? you have me hesistant to execute the file now, since those commands give me error.
demandarin said:
a reboot should clear it. did you enter in commands exactly like listed in op? it tells me file not found. when i unzipped the file, it gives me a tune.sh txt file or whatever. in the commands, is it supposed to be "tune.sh" instead of "ratio.sh"? i see i can just click the file and execute the file like that, bypassing the need to enter in commands. same like with overclock files. i could just execute them manually instead of using an overclock app.
have you noticed any other issues? what benefits have you noticed so far? you have me hesistant to execute the file now, since those commands give me error.
Click to expand...
Click to collapse
PM'd you. it was just an alert. no need for reboot. hard to see or report anything yet.
whycali said:
PM'd you. it was just an alert. no need for reboot. hard to see or report anything yet.
Click to expand...
Click to collapse
Did you guys get this to work, I keep getting the file not found message
whycali said:
PM'd you. it was just an alert. no need for reboot. hard to see or report anything yet.
Click to expand...
Click to collapse
MRCANNADY said:
Did you guys get this to work, I keep getting the file not found message
Click to expand...
Click to collapse
If you want to try the OP's settings, you can easily change these and other virtual memory related settings graphically using the free app System Tuner under "SysCtl". This may be easier for those that don't like messing around with scripts. You can also optionally have the settings to be activated on boot if you test them thoroughly and want them to persist.
I ran
sh tune.sh
as the third command since that was the file name. nothing to report beyond the first one I posted here. I have not sodded yet and have folded my prime closed for a while since implementation.
im getting great results so far. no lag during app store apps updating and installing. plus the apps download and install so fast now. I think this mod along with SIO scheduler, build.prop tweaks, and overclock makes the prime scream speed. no negative drawbacks running this so far. i havent tested playing games yet.
whycali is correct. the filename in the command needs to be changed to what he posted, tune.sh
I am so sorry I changed typo in firat post to tune.sh, my test version had diff. Name.
i am going to try this based on the awesome feedback i have read. i will be testing alongside Chainfire driver and CFQ using ATP Tweak. i will report back. i do have some dalvik tweaks that may yield extreme lag free by forcing zygote to recognize 4 cores along with JIT.
Sent from my Transformer Prime TF201 using xda premium
I don't think that tweaking over heap size and experimenting with JIT will help so much.
This is the cleariest way how to speed up system.
swapiness is useful mainly with swap location but prime doesn't use swap at all.
It's true that these values are agressively focused on smooth UI but it's the point.
I am working on another tweaks.
These things can be of course written to startup scripts to the system, but I don't want to unlock my Prime and when I don't have CWM I won't risk some mistyping resulting to bootloop.
This is the most effective way how to safely reach good performance.
Don't blame Asus that they didn't setup these values, they need to keep some "safe" standards.
Anyway I will try to explore more effective ways.
Guys let me knows your experiences!!
I already tested some heavy applications like Nova 3 and it's working without problems...
Results are in
With out Tune.sh script and SIO at balanced setting:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Same but at Performance Setting:
Now with Tune.sh and SIO enabled at balanced setting:
Same with Performance Setting:
You be the judge. Running .28 ASUS Stock and LOCKED bootloader
Sent from my Transformer Prime TF201 Biotchh

[Q] Sysclt what and how (further explenation needed)

hi evryone i've bin looking around for a while now and i can't seem to find the exact thing/explenation i am looking for.
i would like to know what the following are used for.
simply a more value means this
less value means that
if its possible!
what i sorta get/understand now is the following
Min Free KBytes(obvious is suppose keeping the amount free before it starts killing?)
Dirty Ratio(controls the delay of the kernel writes to data why is this important?so i can control how long it takes for him to flush his memory ?)
Dirty Background Ratio
VFS Cache Pressure(smaller value is bigger cache wich in the end could bite me in the ass ??)
Oom Allocating Task(instead of scanning what to kill it kills whatever made it exceed the memory??)
all i could find on google is people and there prefered settings.
wich could be amazing but aslong as i dont SEE a difference seeing my phone runs smooth to begin with
its rather hard to find out what it does
ty in advance
in case it matters i am using an X10i
feras ng rom
and doomskernel V6 UB
bump.

Categories

Resources