Related
just performed some tests with different reserved mem sizes (stock kernel ZSJP8) for your ref
default settings:
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=16384
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=10240
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1500
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=14336
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=12288
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=36864
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=36864
CONFIG_VIDEO_SAMSUNG_MEMSIZE_JPEG=5012
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=10240
1/. minimum (almost) reserved mem with movie playback possible (no lag in youtube), 356mb memory, no special lags observed, opened 4 tabs in browser with lots of imgs and swfs
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=8192
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=4096
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=6144
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=6144
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=29696**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=29696**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_JPEG=3072
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=2048
** min value in order to play movies = 29mb, 28mb wont play
## can be set to a lower value without movie playback, setting these with too low values caused problems, below 20mb should be ok
2/. nearly double all default values, 219mb available, didnt feel faster
EDIT 201010271843HKT: tweaking memory test2
available memory - 257.68mb
EDIT 201010280000HKT:
as to min mem usage, u'll need to (in brief):
1/. remove unneccessary apps
2/. remove startup/network chg broadcast listeners from the app - a lot of apps/services are launched at startup up or network state chg, remove them so they wont start automatically, eg gtalk, sync/feed, vold service, installd, etc
3/. kill unneccessary services & processes - i didnt use any killer since i rooted my phone, i use script to kill them since killers consume more mem
4/. i have read the source and found that only -Xmx (max mem) is included but no -Xms (initial mem), perhaps we can do something here (not done yet)
reference for 2.1 http://forum.xda-developers.com/showpost.php?p=8507031&postcount=38
It 's very useful info! thanks your test!
Can I have a guide to make these changes to my existing kernel?
Nice, able to see 356MB instead of 304!
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=8192
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=6144
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1500
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=8192
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=8192
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=30720**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=30720**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_JPEG=4096
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=5012
can make one kernel for this setting? i want to test,but i don't know how to make a zimage.
These results exclude the 'blackholed' memory, right? Which means if we can find where it is used (if it is used at all) we can get even more?
Great work there. Could gain us a couple more MB of usable RAM.
The "48MB hole" is most likely used by the GSM Radio and we won't have access to it.
xos84292 said:
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=8192
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=6144
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1500
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=8192
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=8192
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=30720**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=30720**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_JPEG=4096
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=5012
can make one kernel for this setting? i want to test,but i don't know how to make a zimage.
Click to expand...
Click to collapse
i'm sorry, my kernel will restart once the usb cable is unplugged, still looking for a solution....
jam3sjam3s said:
These results exclude the 'blackholed' memory, right? Which means if we can find where it is used (if it is used at all) we can get even more?
Click to expand...
Click to collapse
what blackhole r u talking about?
This is awesome! I can't wait to see a kernel with the resolved usb issue and more ram.
Yay! Finally we have experts working on the RAM issues!
BTW, is there no way to allocate memory dynamically for all these things as and when it is needed instead of reserving a set amount? Especially for the video playback stuff, it's a lot of wasted memory when you're not playing a movie / doing something graphic intensive.
Can anyone explain how to do a safe changes of this paremeters.....?
Thanks
Try 720p video capturing, encoding is hardware accelerated as well. (but might not be affected by those settings, it just needs checking)
Yes, dynamic allocation would be awesome
Those settings are accessible in source code = before compilation, so no way to change them post-startup/post-compilation ATM.
How come u got only around 100MB memory used?
I got over 140 just after startup..
This is still not 512MB as samsung promissed us! I hate this phone! I'll buy a Desire Ultra HD as soon as it's annoucned!
(just to be the first troll in this topic )
nice work though!
sztupy said:
This is still not 512MB as samsung promissed us! I hate this phone! I'll buy a Desire Ultra HD as soon as it's annoucned!
(just to be the first troll in this topic )
nice work though!
Click to expand...
Click to collapse
I don't think that the argument ever was that Samsung promised 512MB of usable RAM. It was that the amount of RAM usable out of 512MB for applications was not comparable to other phones with 512MB.
I don't want this to turn into an argument. I'm just glad that the problem is coming to fruition.
andars05 said:
I don't think that the argument ever was that Samsung promised 512MB of usable RAM. It was that the amount of RAM usable out of 512MB for applications was not comparable to other phones with 512MB.
I don't want this to turn into an argument. I'm just glad that the problem is coming to fruition.
Click to expand...
Click to collapse
You clearly either have no sense of humor or cant read
I know it was sarcastic. He was making fun of the people who wanted more RAM. I was just stating that no one (with exception of a few maybe) expected 512MB of RAM to be fully usuable. I think he misunderstood the original issue
I believe the issue was largely ignored because of this misunderstanding. It didn't help that people who expressed dissatisfaction were told to "stfu." A good portion of people were unhappy with the amount of available RAM. It wasn't that they expected to have full access to all 512MB.
I'm happy to see progress on this issue.
How are we able to change theSe values???
Sent from my SGH-T959 using XDA App
SupaDuckie said:
How are we able to change theSe values???
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
Any kind souls?
SupaDuckie said:
How are we able to change theSe values???
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
mengsuan said:
Any kind souls?
Click to expand...
Click to collapse
How about reading? Its just freakin 2 pages, not 50...
Attention!
If you're looking for scripts, here it is:
[CWM][SCRIPTS][TWEAKS] Thunderbolt!
Script Reviews are here:
Script Reviews
Introduction
I've been meaning to share this with the whole Android community. It seems unfair that only the i9000 folks have access to the vast research that I've done so far. Hence I'm sharing this in the general Android thread in hopes that it'll benefit everyone in the long run
A lot of people often asked about how Android really works and the optimizations can be made to their Android to make it perform better in terms of:
- battery life
- raw performance
- GUI smoothness
With Android based on Linux, and with the experience I have with Linux/Unix (I deal with Unix/Linux on a daily basis for my work) I managed to find some tweaks that we can do to optimize our phones.
I also hope that people will experiment with the tweaks posted here and feedback to me if there are certain ways that I'm doing incorrectly or there are better ways than what I've posted here.
Script tweaks
There are a lot of scripts in XDA that specifically uses the optimizations (Linux or Android based) that I will explain below to actually increase performance/battery life. However, you need to know what those scripts do before using it.
I've done some reviews of the script here:
Script Reviews by Pikachu01
There are good scripts that are properly tested and made sure that it works. It's a script by Zacharias maladroit, the kernel dev who makes the platypus kernel for CM7 and snail kernel for i9000. I modded it to be compatible with i9000 and it'll probably do more than some of the scripts I reviewed
From there, I've also taken the liberty of modifying it some more based on my knowledge and research I've done. It's called ThunderBolt!:
LINK
Now onwards to what actually goes on beneath the hood.
Android Governors
Some custom kernels provide customized governors for you to choose. These are currently known:
- Ondemand (CPU scales to the highest frequency immediately after a certain CPU threshold)
- Conservative (CPU scales to the highest or 1 scale lower than that after a certain threshold gradually and scales down if CPU is below a certain threshold
- OndemandX (Has sleep codes that scales down the CPU when device is asleep. Threshold is set to scale slower)
OndemandX
OndemandX has a suspend frequency that it maintains when the phone is sleeping. It does have a known issue of waking up too slowly when a call comes in.
Conservative
Conservative is used when you would like the CPU to scale to the maximum through each frequency slowly before reaching the maximum. It saves more battery at the expense of smoothness. There are a few tunables that can be configured in Conservative governor, namely the freq_step and both the up and down thresholds.
freq_step is a tunable that determines how much frequency (a percentage of the maximum frequency of your device) to increase at each sampling rate. e.g. you have 5 as freq_step and your maximum frequency is 1GHz. At each sampling rate, it'll increase by 50MHz. If your current frequency is 100MHz, it'll increase to 150MHz at the next sampling. What if your device doesn't support 150MHz? This is done by splitting time between 100MHz and 200MHz (assuming your next frequency is 200MHz) so that in average, your phone is performing at 150MHz.
The up_threshold is how much threshold to wait for before increasing the base frequency to the next freq_step. I.e. if it is 80, the CPU will wait until it is 80% loaded before increasing the frequency. The down threshold is the opposite of up_threshold, which is the threshold to wait until the CPU downscales the frequency to the next frequency step.
Ondemand
Ondemand is a governor that basically a simpler version of conservative. One difference is that it scales to the maximum frequency after load has exceeded a threshold. This is usually 80. After that, it looks at the load again when it's at the max frequency. If it's below 80 (example), it'll scale down one frequency step. The frequency step mentioned here is the available frequency step. I.e. if your device has frequencies of 100,200,400,800 to 1GHz then it'll scale down from 1GHZ to 800, 400 then 200 and 100.
One optimization I have for Ondemand for i9000 TalonDev is that I tuned it to be 80 rather than 65. I have not felt any slowdowns from using this setting and it saves a tiny bit more battery. You can experiment on this value however you want, but bear in mind that I'm not responsible for any slowdowns or damage that is caused by it. Read up a bit more on thresholds to know more (Google it).
I/O scheduler tweaks
Another tweak that can be done is the I/O scheduler tweak. Some kernels come with a few standard I/O schedulers while others have extra schedulers that you can choose from. I'll explain the few that I know and if you have more information on the schedulers, you can post it here for everyone to discuss/share
CFQ - Completely fair. Most will come with this, but this is not optimized for android. Some kernels do optimize it and use it.
Noop - Simple and least overhead of all I/O schedulers. Produces the best outcome for some cases and some do swear by it. It's downside is that it is easily bogged down by high I/O transactions.
Deadline - Optimized for mobile-like devices like Android. Also, some do swear by this. If its writes_starve sysfs is tweaked to be fair, it's the same as SIO.
SIO - It's a fair deadline scheduler. It's the best scheduler. Nuff said.
VR - A newer I/O scheduler that places penalty on reverse seeks. Not for flash drives, though the R penalty can be tweaked to be a multiplier of 1. Even if this is done, it has a high overhead.. Read more here: http://www.gelato.unsw.edu.au/IA64wiki/IOScheduling/VRscheduler
BFQ - Too high of an overhead, it is optimized for spindle disks.
You can pick and choose from Voltage Control or other UV/OC apps and apply it immediately to feel the difference.
Here's my assessment of all the schedulers that I know:
SIO> NOOP> Deadline > VR > BFQ > CFQ
NOOP is a simple I/O scheduler without overhead that tries to do each I/O transaction as it comes (FIFO). When a group of transactions is detected, it will try to merge it together to make batches of transactions (makes the whole transaction faster). NOOP doesn't have starvation detection, hence if an I/O transaction takes a painfully long amount of time, it will still continue to do it rather than switch the CPU into doing something else e.g. GUI interrupts (i.e. scrolling lists, flicking screens). All other schedulers also have the "merge" feature. NOOP is the only one that makes the "merge" feature its only feature.
CFQ is a complex I/O scheduler that tries to determine the address space of the transaction and applies a cost algorithm in that if the address is close together, it will group them up and perform them. It also tries to make the transaction incremental (i.e. reading/writing through address incrementally so that the disk spindle needs to wind down the least in conventional platter hard disks) The problem is, our flash devices have very little delta between reading a far reaching address space (than the one currently being written/read) or a closer one as it doesn't rely on spindle/rotations. Hence, having this costing algorithm adds overhead and slows down the overall transaction. CFQ has a lot of algorithms to make sure each process gets a fair slice of time on I/O transcations. Too much overhead.
Deadline has a starvation detector and is simple enough that it doesn't have all the overhead of doing rotational/costing disks algorithm. However, reads are done 2x more likely than writes as it has a algorithm based on weights in that reads must be done first if both a read and a write is detected. It has a 2:1 ratio of read to write weights coded into the scheduler (that can be tweaked - writes_starved, will include it in the next version of system_tweak). Hence it's not a fair scheduler.
SIO is Simple I/O that tries to implement a NOOP type scheduler that has starvation detection. Hence, long I/O transactions will be preempted and given CPU time only after other faster transactions are completed, guaranteeing smoothness. Also, it doesn't have overhead of calculating costs. Also, it has a fair number of writes to read, guaranteeing that all transactions are equal.
BFQ has a lot of algorithms to make sure each process gets a fair slice of bandwidth (Budget Fair Queueing). Too much overhead.
V(R) tries to make sure that each transaction has a weight associated with it, being R. And if the seek is reversed, the R will be multiplied by a penalty making it less likely to be processed. Not for flash drives as reverse seek in a flash drive is just as fast as a forward seek.
In benchmarking tests, the tests normally consists of testing the time it takes for a contiguous I/O transfer from 1 point to another. NOOP excels at that because it won't let itself get interrupted to perform another I/O task. This would mean that in real life testing, NOOP will let a long arduous task to finish while at the expense of UI functionality (you will get UI lags)
SIO on the other hand will perform badly at benchmarking as it gets pre-empted when the contiguous tasks takes more than 0.5secs (for synchronous tasks as benchmarking tools perform a synchronous I/O task from one point to another) to another more important task like UI interrupt (when you're scrolling) or Kernel interrupt (when your kernel needs to perform garbage collecting or swap memory etc)
The 0.5 secs can be tuned in the SIO tuneables though, but I would think 0.5 secs for synchronous tasks and 5 secs for async tasks is pretty good to maintain a balance between long/short tasks enabling a smoother experience in Android.
LowMemoryKiller
The LowMemoryKiller is a constant debate between more free RAM and more multitasking capabilities as free RAM (more than 60MB free) is actually wasted RAM. The fact is SGS only has a puny amount of RAM left after a few big chunks are allocated to the Graphics, Modem, Sound and Video (and some others that I do not know a lot about). With that knowledge, Samsung decided to give the SGS SL a bigger amount of RAM when they released it ( about ~650MB of RAM read that from somewhere, can't remember).
The LowMemoryKiller is actually a feature in the Android OS for better memory management.
You can read about it more here:
http://forum.xda-developers.com/showpost.php?p=5442369&postcount=1
This is an important feature due to the perennial problem of having low free memory causing lagginess and slowness in launching apps. When you have free memory lingering around the number of 40MB or less, the Android OS just lags like hell.
What this would mean is, you would want to tweak the LMK to not have the situation of it having less than 40MB (or even close to that).
The modern Linux machine in the Android ecosystem relies on a mechanism called Low Memory Killer (LMK) to consistently free up RAM. This is due to Android's internal mechanism of caching apps (and never fully exiting them) when you press the back button. This is to enable faster app switching and provide a seamless experience for apps usage model. Android also, by itself will also constantly look for often used apps to cache them for faster app opening. This will happen even before your system fully boots.
Now, when you mention LMK, the most obvious thoughts that come up are minfrees and Out Of Memory (OOM) groupings. Yes, those two are integral parts when it comes to LMK. The issue here is that no one actually mentioned that there are two LMK systems in Android, that being:
- Linux LMK
- Android Dalvik VM LMK
Both are separate entities that kills/removes app/dalvik cache from RAM when RAM reaches a certain level.
What confuses most people (including me) is that the OOM groupings of both mechanisms have the same names being (Android 2.3 based):
LMK App Categories
FOREGROUND_APP: Your apps in the foreground, being used currently, interfacing with the user.
VISIBLE_APP: Visible app that is still viewable by the user, but not interacting with the user, example could be apps that reside in the status bar, and giving live information i.e. Os monitor graphs.
PERCEPTIBLE_APP: App that the user can still perceive i.e. Music app that is playing music.
HEAVY_WEIGHT_APP: RAM heavy apps that are not being interacted with, but will be a pain to load if its information is cleared in the memory.
SECONDARY_SERVER: App that acts as a secondary server. Not sure what this really means, but client-server thingy but secondary? Could be something that syncs with an app, but is not syncing currently?
BACKUP_APP: App that is currently making a backup (like Titanium backup?)
HOME_APP: Your launcher.
HIDDEN_APP: An exited app that still significant residual memory in the RAM. Exited only some time ago, or is constantly used by the user.
EMPTY_APP: An exited app that only has small remnants of residual memory in RAM. App that is exited quite some time ago.
Take note that this is my understanding of the OOM groupings. If there are mistakes, please correct me
Tuning LMK
Both the LMK and Dalvik VM has this groupings and they can be tunable by using prop and lowmemorykiller/parameters/adj respectively.
One errata about this is that the Dalvik LMK has one extra tunable which is CONTENT_PROVIDER, which affects widgets that are not currently refreshing or displaying information. The ADJ (which I will explain later) is not available to be tuned though. And it is clearly missing from the Linux LMK.
The ADJ is the so-called priority of the app categories, with 0 being the highest (should not be killed) and 15 being the lowest (should be the first to be killed). I haven't seen values other than 0-15 but I have a feeling that the numbers are arbitrary, and can be extended up to 65535, but who would want to do that since they're only 9 app categories
LMK are specified by pages, with memory = 4 * pages.
e.g.
4096 pages represents 16MB RAM (16 *1.024)
From the Linux LMK source code, the parameters can be adjusted as such:
Code:
* For example, write "0,8" to /sys/module/lowmemorykiller/parameters/adj and
* "1024,4096" to /sys/module/lowmemorykiller/parameters/minfree to kill processes
* with a oom_adj value of 8 or higher when the free memory drops below 4096 pages
* and kill processes with a oom_adj value of 0 or higher when the free memory
* drops below 1024 pages.
Take note that the oom_adj so far takes only 6 values (although I am confident that it can take more than that). Haven't experimented enough to validate that, but I shouldn't need to as assigning different oom_adj should be a given for all the app categories. This is to make the LMK intelligent enough to determine which app to kill first rather than grouping different app categories into one priority, in which a lot of popular LMK settings that devs provide do that.
And for the Dalvik LMK, my understanding is that it will remove all dalvik caches of <INSERT_APP_CATEGORY_ADJ> or higher if free RAM/pages reaches the level specified.
Hence, two things are learned here:
- Linux LMK will kill an app category of that particular RAM level or higher if free RAM drops below a certain level e.g.
Hidden_APP has a minfree of 16384 pages. If pages fall below this level, Empty_App will be killed first, free pages is recalculated, then if RAM is still below that, Hidden_Apps will be killed next.
- Dalvik LMK will clear all dalvik caches in RAM of all the App category if free RAM reaches the level e.g.
SECONDARY_SERVER_MEM is 8192 pages. When RAM reaches 8192 pages, all SECONDARY_SERVER caches are cleared.
Best Practices
Now, how do we tweak both so that it is efficient in doing its job, i.e. LMK.
From my experiments I can safely say that:
- Below 60MB free RAM you will feel lag 5-10% of the time.
- Below 52MB free RAM you will feel lag 5-15% of the time.
- Below 46MB free RAM you will feel lag 15-20% of the time.
- Below 42MB free RAM you will feel lag 20-50% of the time.
- Below 36MB free RAM you will feel lag 100% of the time.
The experience of lag increases exponentially from 60 down to 36MB. Hence, the LMK should be tweaked against that.
Also, it is considered best practices to group oom_adj settings of Linux LMK with the Dalvik LMK as when free RAM drops to that level, both the Linux LMK and Dalvik LMK will work together to free up at both sides.
The 6 oom_adj that can be tuned for Linux minfree also need to be tuned correctly, failing this would make the LMK too aggressive/under aggressive in mid levels (even if your EMPTY_APP is aggressive, if your oom_adj is selected incorrectly, you'll get to a point where memory leak occurs).
Talon LMK - This is obsolete, TalonDev is using ThunderBolt! LMK from 0.5.x
Take for example, the Talon default LMK setting where:
LMK_ADJ is 0,1,2,3,7,15.
It's EMPTY_APP is 15
It's HIDDEN_APP is 5
It's HEAVYWEIGHT, SECONDARY and BACKUP is 3
Last three values of MINFREE is 4096, 9216, 12288.
Where's the issue here? If you noticed it congrats.
If you didn't, here's the issue:
The minfree 12288 is tied to EMPTY_APP which has a OOM_ADJ of 15.
The minfree 9216 is tied to nothing but has a OOM_ADJ of 7
The minfree 4096 is tied to HEAVYWEIGHT,SECONDARY and BACKUP with the OOM_ADJ of 3.
The LMK_ADJ is important as it represents the checkpoints where the Linux kernel will check for minfrees and kill them. Here's a situation:
Memory is below 12288 pages, OOM is triggered and Linux looks for EMPTY_APP to kill and kills all of them. Job done. Memory is back to >12288 pages.
After a few days, memory is below 12288 pages again, OOM kills all EMPTY_APP, but free memory is still lower than that. It sees if the next checkpoint is fulfilled, which is 9216 pages, and yes memory is still below 9216 pages. It looks for an OOM_ADJ of 7 and above to kill, but fails to find any as 7 and above OOM_ADJ only consists of EMPTY_APP.
Here comes the quandary. The next checkpoint is 4096. We're not ever going to reach that as you'll need memory to fall below 16MB, and at that time it'll be super sluggish to even support GUI. Hence BAM, memory leak or lag or something.
Supercharger LMK 512HP - Multitasking
Let me just paste this to avoid a lot of retyping
Code:
FOREGROUND_APP_ADJ=0
VISIBLE_APP_ADJ=4
PERCEPTIBLE_APP_ADJ=2
HEAVY_WEIGHT_APP_ADJ=5
SECONDARY_SERVER_ADJ=6
BACKUP_APP_ADJ=7
HOME_APP_ADJ=1
HIDDEN_APP_MIN_ADJ=8
EMPTY_APP_ADJ=15
FOREGROUND_APP_MEM=1536
VISIBLE_APP_MEM=3072
PERCEPTIBLE_APP_MEM=1024
HEAVY_WEIGHT_APP_MEM=10240
SECONDARY_SERVER_MEM=10240
BACKUP_APP_MEM=15360
HOME_APP_MEM=1024
HIDDEN_APP_MEM=15360
EMPTY_APP_MEM=25600
LMK_ADJ="0,4,6,8,14,15"
LMK_MINFREE="1536,3072,10240,15360,20480,25600"
A few things here:
It's EMPTY_APP and HIDDEN_APP is too large, 80 and 100MB respectively, but the 80MB is a false flag hence it doesn't really matter if you tweak that and you can get a very minor degree of multitasking because of this false flag. I'll get to that in a moment.
It's PERCEPTIBLE_APP has higher OOM_ADJ than VISIBLE_APP (odd selection, but RAM rarely goes below 40MB before it starts lagging like hell) People would reboot their phones when it gets to that, but it rarely gets to that for this configuration as LMK is pretty aggressive here.
Now, it's LMK_ADJ is "0,4,6,8,14,15"
15 is EMPTY_APP,
14 is nothing
8 is HIDDEN_APP - it looks like it'll only kill HIDDEN_APPs when it reaches 60MB, with HIDDEN_APPs being the heavy hitter of apps as most apps will end up in this category. Hence why multitasking is still doable (to an extent) but an aggressive LMK means taking a call or switching to a browser will kill your game (losing saves). Inconvenient, but it works for some people who haven't played a long game without saving and never took a call in between. Imagine the horror LOL!
Juwe's RAM Script
Code:
if [ -e /sys/module/lowmemorykiller/parameters/adj ]; then
echo "0,1,2,4,6,15" > /sys/module/lowmemorykiller/parameters/adj
fi
if [ -e /sys/module/lowmemorykiller/parameters/minfree ]; then
echo "2560,4096,5632,10240,11776,14848" > /sys/module/lowmemorykiller/parameters/minfree
fi
No OOM_ADJ are given, hence the stock ones are in effect here.
From init.rc, this is the stock 2.3.5 OOM_ADJ.
FOREGROUND 0
VISIBLE, PERCEPTIBLE 1
HEAVY_WEIGHT, SECONDARY_SERVER, BACKUP 2
HOME 4
HIDDEN_APP 7
EMPTY_APP 15
This one also suffers from the false flag of the 2nd last minfree not being used. It will start killing HIDDEN_APP at 40MB, which is usable (you'll only get lags 15-20% of the time, and most probably after long usage). Other than that, it's pretty stable.
Misc
There are a few known scripts that tweaks the LMK as well as the app priority (yes, the priority of the process categories can be changed too by using setprop.)
Supercharger is one of them:
http://forum.xda-developers.com/showthread.php?t=991276
Take note that Talon doesn't permit Supercharger to be used (it will override it when booting through boot scripts) as Talon itself uses its own LMK settings that are optimized for ZRAM/Swap.
Kickasskernel script is also included in Supercharger. The script will clash with Zach's script in ThunderBolt! too as both of them tries to set different values for the same settings.
Note that Zach's script doesn't tweak LMK settings as i9000 Talon doesn't permit it. With that, if you're using Zach's scripts, you would need to find other ways of tweaking the LMK. Using Auto Memory Manager is good. You can download Supercharger, look at the presets and apply it using Auto Memory Manager. The preset is the only thing important here
LMK App Category Priorities
Using setprop, there is a way to set the priorities of the category. Since, app categories are different, I can only offer one recommendation: The HOME_APP_ADJ.
This prop setting sets how high of a priority your launcher is. A 1 or 2 is sufficient to make sure your launcher doesn't get killed. However, do you really want it to be on 1 or 2. Based on the previous article (LMK/OOM), you would know that OOM priorities are comparatively based on one another. Setting it 1 or 2 in stock 2.3.5 values would basically override PERCEPTIBLE/VISIBLE app priorities. Do you want your launcher to be killed only after your keyboard/music player to be killed? You decide
Journaling/Barriers
This has been a touchy subject here in XDA for most people who debate about it. Most recently, the SAS/Acid tweaks included a way to disable journaling on these partitions:
/system (System is read only, it's safe to remove journaling. However, you will not see speed increase by removing it as you're not writing onto /system 99.99% of the time unless you're using Titanium backup to remove system apps or copying init.d scripts to it)
/cache (Cache can be rebuilt on the fly. Data corruption on it is not game breaking)
/data (All of your data on your phone is here. Removing journaling can risk data corruption. Read more below)
On whether we need journaling or not, I will pose this situation:
Journaling is required to maintain data consistency in events that could lead to data corruption. Data could get corrupted in a number of situations:
- Misbehaving app that constantly writes without syncing/committing data to the disk
- Power loss due to forced reboots or bootloops when data is partially written/committed into disk
Android will normally buffer its writes before committing to the disk. This way, data stays in the RAM before data would only get written into the disk after a period of time. Take note that we as Android enthusiasts seek ways to better our phone to get the most out of it through experimental and sometimes wacky ways. Take OC/UV for example. When we OCed or UVed too much, sometimes our phone will get deadsleep or constant reboots. This leads to corruption if journaling is not turned on. However, we can get corruption too even with journaling but the risk is smaller.
Mount options too, play a role in whether journaling can be safe/unsafe. Most lagfixes will place a "barrier=1" in the /data to make sure that journals are actually committed before an out-of-order write is done. With that, the risk is greatly reduced at the cost of performance. You could experiment by removing barriers and see if it works for you. No guarantees on data if you remove barriers! More info on ext4/barriers:
http://lwn.net/Articles/283161/
http://kernelnewbies.org/Ext4#head-25c0a1275a571f7332fa196d4437c38e79f39f63
If you do disable journaling, make sure to manually run an fsck on your disk. Make sure the fsck binaries are in your binary paths (echo $PATH to show your binary paths). Don't ask how to do this if you're unable to do fsck. It is your own risk that you are disabling journaling/barriers.
One experiencing I would like to relate is this:
I've personally disabled ext4 journaling on my device. After experiencing a sudden power loss (forced reboot), my apps started FCing left and right and device became unstable that it sometimes rebooted when the device is sleeping. In other words, it's a lost case. Reflashing was the only way to restore my phone. This happened 1 day after disabling my journals.
Also note that ext2 is basically an ext4 without journaling. However, ext4 is updated all the time while ext2 source is not updated for quite some time (2 or 3 years?). Most optimizations are already in ext4 while ext2 even without journaling is slower than ext4 without journaling. A comparison of performance:
No journal:
ext4 > ext2
With Journal:
ext2 (can't do journaling in ext2) > ext4 > ext3
Update: Attached is a JournalingOn.zip for i9000 only that you can flash to rejournal your partitions (Only for i9000 devices!). Also attached is Acid Tweaksv6 - Removed Useless Stuff that will disable journaling only for /system and /cache, if anyone is interested. You will need to rejournal first before unjournaling. To be sure that /system and /cache has no journaling and your mounts are applied correctly, type "mount" without the quotes.
You'll be able to see that /data will have:
Code:
barrier=1, data=ordered
/system and /cache will have:
Code:
barrier=0, data=writeback
To be really sure, you can check by using tune2fs included in both the JournalingOn.zip and Acid Tweaksv6 - Removed Useless Stuff.zip.
Copy the tune2fs to /tmp and set rwxr-xr-x as its permissions using Root Explorer/File Expert
Code:
/tmp/tune2fs -l /dev/block/mmcblk0p2 | grep features
You can substitute the /dev/block/mmcblk0p2 (which is /data) to /dev/block/stl10 (/dbdata) /dev/block/stl9 (/system) /dev/block/stl11 (/cache) to check each partition.
Continued in Post #2 - Lack of space
Still posting ...
Question
I guess this is safe too on a deodexed ROM, too freeze those bloatwares u listed?
Page 2
Undervolting/Overclocking
This is also another touchy subject, but more towards people complaining about phones that get forced reboots or bootloops. OCing is done to get better performance on your android. WARNING: Ocing will cause more wear and tear on your CPU and will reduce your CPU lifetime. How much it will reduce it? No one knows. It depends on how sturdy your CPU is, and that cannot be measured by any means. It could be reducing months out of year e.g. 6months out of 3 years? No one actually knows.
UVing on the other hand reduces battery drain especially when you UV your 100MHz as 90% of the time in normal usage, your CPU will idle at 100MHz. How much can it save? No one actually did a benchmark on it. Save to say, UVing does not harm your CPU, it will actually extend the life of it by reducing wear and tear Oh, bootloops do corrupt data if you're without journaling
Always remember to clear your UV/OC settings before flashing another kernel!
Take note that the ability to OC/UV depend on your phone. Some SGS can UV better or OC better and some might not.
On how to UV:
1. You can UV more on the lower frequencies than the higher frequencies.
2. Do a UV for
100MHz with (950-150=800) - Take note that 950 is the base value for the voltage. Some kernels might have changed this value to 925 or 900. This is why clearing your OC/UV settings is important as the OC/UV settings will only load the voltage difference, which in this case -150. If the base voltage is 900 and you do a -150 for it, you'll end up with 750 which might cause bootloops.
3. Limit the max frequency to 100MHz. WARNING: Doing this will significantly slow down your system to a crawl, but it is still running. This is done only to test the stability of your system. You can skip this if you want, but you would need to find a way to stress test your CPU at the 100MHz value (and other values as well by limiting the max frequency). Failing in testing this will result in deadsleeping (as your phone is in 100MHz when you sleep and if you undervolt too much, you deadsleep)
3. Test with RockPlayer (or MX Video Player) and play an RMVB file using software decoding for 10mins. If your settings is unstable, Android will freeze up and reboot. (this is just an example, but I find that this way stresses the CPU to the max. I fail to find another way of stressing it as even playing NFS is stable on some voltages but fails when I play rockplayer. Hence rockplayer is the best way so far)
4. After doing this, remove the limit and move on with the next few frequencies.
The rest of the voltages, just rinse and repeat.
200MHz with (950-100 = 850)
400MHz with (1050-75 = 975)
800MHz with (1200-25= 1175)
1000MHz with (no change)
You can experiment with lesser values than these if you get freezes/bootloops as this is by no means a one size fits all value. Some might think this UV is overly aggressive or some might think that this UV value is too underwhelming.
Mine if you're interested:
Code:
100MHz = -200 (950 base)
200MHz = -150 (950 base)
400MHz = -125 (1050 base)
800MHz = -75 (1200 base)
1000MHz = -50 (1275 base)
As for OCing, you would do the same to test the stability. Just that you will be enabling a higher clock for your L0 frequency (L0 is the highest frequency). Some kernels might add more frequency states i.e. from the 5 states above to 6. You can try using Tegrak OC app too. It all depends on your own experimentation.
Memory Leaks
If you found out that your Android is laggy after sometime and a reboot will make it faster, then you're experiencing memory leaks. "free" is a command to show your currently free memory. It will not necessarily be the same value as your phone's free memory (as it takes into account swaps and buffers)
1. Go to terminal emulator (or download the script at Post #3)
Code:
su <ENTER>
free <ENTER>
This will show your buffers and free memory.
My example:
Code:
total used free shared buffers
Mem: 348548 340280 8268 0 1320
Swap: 163836 47292 116544
Total: 512384 387572 124812
Then do this:
Code:
sync <ENTER>
echo 3 > /proc/sys/vm/drop_caches <ENTER>
Type:
Code:
free<ENTER>
And you'll realize that the buffers will reduce and free memory will increase, like this example:
Code:
total used free shared buffers
Mem: 348548 305212 43336 0 88
Swap: 163836 46804 117032
Total: 512384 352016 160368
That means it's done.
Click to expand...
Click to collapse
If this solves the laggginess problem, it's due to vfs_cache_pressure being too low and dirty_ratio being too high. However, in most cases, you don't have to do this as Linux will manage to clear the RAM in a timely manner as long as there are no apps that constantly hold on to the memory (not releasing it). Hence, only do this when necessary (lagginess and such).
With that, I've updated the system_tweak yet again, with this knowledge by making the VM settings more aggressive, which will trigger the memory leak faster. I made this so, as there's a workaround to clear the caches when it gets full.
Having a low vfs_cache_pressure and a high dirty_ratio will save battery and make your device perform faster at the cost of higher RAM usage.
You can actually automate it by using Script Manager by making a script, pasting the instructions and making a widget out of it. To learn more, read the android market description or the in-help guide in the app.
Some commonly asked questions about drop_caches that were answered by me from flolep:
http://forum.xda-developers.com/showpost.php?p=17727859&postcount=3428
http://forum.xda-developers.com/showpost.php?p=17731938&postcount=3446
http://forum.xda-developers.com/showpost.php?p=17736421&postcount=3450
Checking for Battery Drain/ Saving battery
Starting from Gingerbread, you can't really look for Partial wakelocks anymore to determine what is draining your battery at night. BetterBatteryStats is a way to check for that. It also can provide the process that drains your battery most of the time.
A high partial wakelock usually says that something is waking up your phone at night. With that, checking partial wakelock, you can see if these are the culprit:
-Network Location
-Location Manager Service
If so, disable Lattitude or any location check-in app that you're using. It's checking you in every few minutes that drains the battery.
Disabling Wifi/3G/HSDPA saves battery too. I find that Wifi/Edge drains the least amount of battery when idling. To switch to EDGE as opposed to HSDPA/3G.
Go to:
Code:
Settings > Wireless > Mobile Networks > Network Mode > GSM Only
Disabling "Use Wireless Networks" in location and security would save a little bit of battery too I guess. It's in:
Code:
Settings > Locations and Security > Use wireless networks
CSC
CSC is a folder that defines your APN settings and country/region specific configurations aside from Language/Time that is configured in build.prop(also for Samsung Apps).
Having to manually set your APN is annoying right?
Your product code being KOR by default is another annoying thing to deal with. How do I resolve this?
1. Get your CSC from your own country here: http://forum.xda-developers.com/showthread.php?t=948790
2. Extract from the zip file /system/csc/<folder> (where <folder> is your Country's CSC)
3. Use Root Explorer/File Expert to copy it to the phone's /system/csc/.
4. Use nitrality to change your product code. WARNING: This will wipe all your data.
Odexed vs Deodexed
I've been using Deodexed ROMs since I first flash my custom ROMs. One gripe I have is that I seem to have lost the stock smoothness/speed that I experience when I'm using a stock ROM. I found out that deodexing actually extracts the customization files back to the APK (using APK manager) and Odexed files are actually done to optimize the speed of those files itself.
The only reason ROM chefs are using deodexed files is that it is easier to theme. There is no need to decompile the odex files and make the changes as all the theme files are in the APK themselves.
Only other reason that I know of is the overscroll glow. Odexed files can't support it. However, that is a small price to pay for speed/smoothness that I am willing to sacrifice.
Busybox
Busybox is required to perform all of your superuser activities in your android phone. There are some problems associated with this when ROM developers decide to use a certain version of Busybox that are incompatible with the binaries that we use in our phones. When you found out that after changing your kernel/ROM:
- You still have superuser and Titanium Backup still works but,
- Root Explorer/File Expert can't copy files correctly to the /system after mounting rw
- Voltage Control/ Pimp My CPU/ Control Freak/ SetCPU cannot create the Svolt_scheduler file in /etc/init.d
You have a clashing busybox version issue. This can be remedied by:
- Installing the busybox installer from the market
- Installing busybox 1.17.x into /xbin
- Removing all other busybox binaries from your binary path. (This is optional if you found out that after installing busybox, everything works. Try it first before removing) To know your binary path, do an
Code:
echo $PATH
Nandroid Backup
Nandroid Backup is done in recovery (VolumeUp + Home + Power). In recovery, choose Backup And Restore. What it does is it backs up your:
- Boot
- System
- Data
- Cache
When you restore, you should preferably use Advanced restore and restore the /system and /data. All others can be built from scratch (except /boot). If you're converting from CM7 to Samsung Roms, it's best to start from scratch either ways. Restoring nandroid from any is considered dangerous and not supported by most cases. Best is to use Titanium Backup to backup as it can be restored both ways (only restore app though, restore data sometimes can lead to FCs)
Voodoo Color
Voodoo Color is also a point of contention among users. Some like it and some hate it with a passion. If your kernel does support it, here's a way to tweak it:
1. Tweak the color profiles. Can't see a difference, hence I would just pick Voodoo most of the time.
2. Tweak the gamma first to a comfortable value. I.e. drag the 3 sliders together to a comfortable gamma level. After that, try looking in the gradient (the gray slab below the slider) and try to find for neutral gray values. Adjust each slider until you find a neutral gray (i.e. left and right until you see that slab is truly gray)
3. Tweak the RGB multiplier until you have a comfortable level (3 sliders together). Then tweak it the same by referring to the gradient until you're comfortable.
4. Switch off your display for a while and look at your surroundings to reset your eyes. Then turn on your screen again and see if its too green/yellow/blue etc. Adjust the gamma/RGB multiplier until you're satisfied.
This might take a few rounds of testing, but in the end you'll be truly satisfied with it
i9000 Specific
i9000 Kernels - In Depth
You will need to have a stock odexed (why odexed? read a few passages below)ROM with root. You can easily do this by flashing stock XXJVS 2.3.5 and then flashing a custom kernel through Odin like:
- Dark Core - Uses Voodoo initramfs
- CF-root - Uses CF-root initramfs
- Semaphore - Uses CF-root initramfs
- Midnight - Uses Speedmod initramfs
- Galaxian - Uses CF-root initramfs
- Voodoo - Uses Voodoo initramfs
You can flash the custom kernel through Odin by placing the tar file into the PDA section and pressing Start. At this point, do not convert your partitions to ext4 (lagfix) unless you're using a Voodoo based initramfs as Voodoo based initramfs will convert your partitions to ext4 automatically at first boot.
After flashing a custom kernel through Odin, you will gain root. From there, you can choose to use any other custom kernels that use CWM to install or stick with the custom kernel that you've flashed through Odin like:
- TalonDev - Uses Voodoo initramfs
- TalonSH - Uses Voodoo initramfs
There are other kernels as well, but since I did not stress test them, I will not include them here. This thread lists the full repertoire of custom kernels that you can choose from:
http://forum.xda-developers.com/showthread.php?t=1196704
On which custom kernel to pick, you're advised to look at the individual threads original post as well as the last 5 pages of the thread to know about its stability and features. I pick TalonDev myself as it has compache as well as the latest upstream (kernel updates from the Linux OS as well as the official Android Open Source Project/AOSP and optimizations) patches.
At this point, you should decide if you would want to convert to ext4 (lagfix) or not. Your phone by default will reside in an RFS system. The RFS at this point in time is pretty stable and its performance can easily match ext4. Too bad Quadrant scores are bad for RFS, but who cares about Quadrant anyways. I myself choose to use ext4 as the TalonDev kernel has a lot of ext4 upstream patches that optimizes the usage of ext4 on Android.
If you're using Voodoo initramfs, you'll be converted to ext4 automatically.
If you're using CF-root initramfs, you will require the CF-root ext4 app to convert that can be found here:
http://forum.xda-developers.com/showpost.php?p=12651371&postcount=7
Note that on some kernels that use CF-root initramfs, the ext4 app will warn you that you're not on CF-root type kernels. Ignore this warning. You'll be able to convert to ext4 anyways unless you're on Galaxian. Certain Galaxian versions (since the kernels are not versioned, I can't tell which versions are not working) will bar you from converting to ext4 using the ext4 app. If that is the case, just flash CF-root, convert to ext4 and then flash back to Galaxian.
Also not that CF-root based initramfs kernels will remove your bootsounds on first boot. Don't be alarmed by this.
In terms of which lagfix is better (Voodoo vs CF-root lagfix), I can't tell at this point in time. Both are equally good. Since TalonDev uses the Voodoo initramfs, I am inclined to use the same when I am using the same kernel. That should be a good yardstick to follow.
BIGMEM/ Non-BIGMEM:
Some kernel developers released BIGMEM versions of their kernel:
-TalonDev BIGMEM
-TalonSH BIGMEM
-Semaphore bm version
The only difference a bigmem kernel can bring is more memory at the expense of 720p video recording. Playing a 720p video is still possible. Recording it is not on a bigmem kernel. Bigmem kernels normally have 13MB more than their non-bigmem counterparts. How this 13MB could affect you? It depends on the apps you use and how aggressive your LowMemoryKiller is.
XXJVT System apps
System apps can be frozen/removed to make your system faster/less battery draining.
In order to remove/freeze system apps, you would need Titanium Backup (Pro) or System Tuner.
The choice whether we want to remove or freeze the system apps should now be decided. Titanium Backup Pro and System Tuner uses a built in Android mechanism to freeze your system apps - PM disable. PM disable will actually disable the app from the system itself. It will not drain the battery or even launch itself. It is a safer way so to speak. Removing will physically delete the APK app from the system freeing up disk space. If you decide to remove, make sure to have a backup before proceeding. Even if you have a backup, restoring from Titanium Backup may sometime fail. Hence, do this only if you're sure you want to remove that certain app. Freezing an app will make it easier to defrost without any consequences.
Here are the apps that I disabled:
Code:
AngryGPS > Used to manually configure GPS. Not needed if GPS works OK.
BluetoothTest
Buddies Now
lcdtest
screencapture > Screen capture app
Daily Briefing
Days
EncryptApp
Factory Test
Gallery -> I use QuickPic as a replacement. It's faster than Gallery.
Google Partner Setup
Google Search > Google search widget
Home screen tips
HTML Viewer
Market Feedback Agent
Market Updater > I froze this to avoid being updated to Market 3.0. It currently sucks now
Mobile tracker > Mobile tracker, only if you use it, then keep it
Mobile tracker settings > Mobile tracker, only if you use it, then keep it
Perso
PhoneSetupWizard > Required if you're first booting/installing the ROM, not needed afterwards
PopupuiReceiver
Press Reader
Print via Bluetooth
RoseEuKor
Samsung Account
Samsung Keypad -> I use Swype beta instead
Self Test Mode
Service mode
SimDetachNotifier > Will notify you if you detached your sim card. Seems pointless
SNS > Only necessary to sync your contacts if you're using Social hub to do so or syncing calendar from Facebook
SNSAccount > Same as above
Social Hub
Software Update
Synchronise
TwLauncher -> Using Go Launcher Ex instead
wipeoutreceiver > Wipe if phone is stolen. Not needed if you don't use the Samsung service
WlanTest
wssyncmlnps
There are others that you can remove as well. I'm hoping to gather feedback on the other APKs that can be removed and what will be affected by its removal. Please post if you have more information
Disabling Lagfix
Most ROMs would advice you to disable lagfix before flashing a new ROM. Although this is not necessary in most cases (as all Gingerbread kernels support ext4 from the get-go) moving from one kernel to another might need it (to optimize the initramfs it is used on). Hence if you're swapping from one kernel (that has a different initramfs) to another. It is adviseable to undo the lagfix.
CF's lagfix can be undone by using the ext4 app.
Voodoo lagfix can be undone by using the Voodoo Control App.
Speedmod lagfix can be undone by using it's recovery.
Odexed ROM
You might say, hey if I'm using stock, I'll be missing extended power menu, battery percentage and all other theme mods that are not in the stock ROM. Fear not, you can get all these back including Gtalk2, CRT screen off etc here:
$omator's stock+
Gtalk2
There are odexed themes too, in which the developers would decompile the odex files into APKs, make the changes then compile the APKs into odex files again. It is more tedious than deodexed themes but odexing generally makes the phone smoother
You can find the themes here:
http://forum.xda-developers.com/forumdisplay.php?f=666
WIFI Issue on JVR/JVS/JVT
You might be facing some wifi connectivity issues on JVR/JVS/JVT ROMs i.e. it disconnects every few seconds.
This is due to some changes in the ROM that doesn't permit a "Forever" lease time from your modem. Change your lease time to an hour (or two) or if you don't have that option, remove your address reservation option from your modem (Yes, it's a modem only tweak, nothing you can do on your phone)
Memory Freak
Memory Freak is an app in TalonDev that tweaks the ZRAM/Swap and LMK settings. There's a golden rule to the ZRAM/Swap that is:
Swapping to and from the ZRAM will be slower if the amount of ZRAM is more than 50% of the total usable memory, . Hence, I set mine to 160MB (from the 340 total usable RAM). Swappiness in most Linux machines is 60. This means, the system will be inclined to swap in/out more than just using the RAM. I set mine to 50 as a personal preference so that there would be 50% chance that the system will use swap or RAM.
HiddenApp is the amount of free memory to be when LMK starts looking for hiddenapps to kill. I set mine to 52 for my multitasking preference. Experiment with it to see how much multitasking vs smoothness you're looking for. My preference will change in time. Check my signature for the most updated ones.
WIP:
This is obviously a work in progress article that will undergo changes as the Android scene improves. I will spend time to make edits and additions to the post whenever I see fit. Sometimes I will post changelogs at the end of the thread, sometimes I won't if I only make minor edits. Just be sure to check back often to see any new tips offered
Credits:
I claim no credit on these findings except for the ones that I've researched on my own. However, all of it is not of original work since I form my own opinions after reading a lot. I also don't claim that the settings I posted are the most optimal there is. It might not even work well for most of you guys. The key here is tweaking it to your own perfection as there is no setting that will cater to everyone's needs. Hence the real people who deserve credits are:
* All the devs' kernel/apps that I posted here
* XDA forum
* Google
Attention!
If you're looking for scripts, here it is:
[CWM][SCRIPTS][TWEAKS] Thunderbolt!
Script Reviews are here:
Script Reviews
GUIDE UPDATES
UPDATE 1/10/12
* Edited some sections with some new knowledge that I have. A few places, can't name them all Check them out and see if you can spot them.
UPDATE 10/19/11
* Moved around some guides and grouped them together
* Updated some guides to make them more Android centric (as opposed to i9000 centric)
UPDATE 10/18/2011 - Added an indepth article about LMK/OOM. CTRL-F for LMK.
UPDATE 10/12/2011
* Added some comments on the apps removed/frozen so that you can make an informed choice of why the apps can be removed/frozen.
* Added my analysis of most schedulers that I know of and why they are good/bad.
* Moved the scripts to ThunderBolt!: LINK
* Added a guide on the wifi issue for JVR/JVS/JVT
UPDATE 10/1/2011 - Moved the script reviews to this post LINK
UPDATE 9/23/2011:
* Removed the JournalingOn.zip and Acid Tweaksv6 - Removed Useless Stuff.zip because people might use it for devices other than the i9000. This is because in other devices such as SGS4G, the /dev/block/stl10 is /data while in i9000 it's /dbdata. The JournalingOn.zip will not enable journaling on /dbdata without some editing. Hence, I removed it as I don't have a time to put up a warning or notice, and didn't have time to edit the script inside the zip file.
* Readded an edited JournalingOn.zip and readded the Acid Tweaksv6 - Removed Useless Stuff.zip (did not change) to the first post. Only for i9000 devices!!
* Added another way to check if you're journaled or unjournaled. Check the guide below.
* Added some more explanation on common scripts I found.
* Moved the guides around due to lack of space. I added some minor changes to most of the guides. See if you can detect them
Helpful!
pikachu01 said:
Yes it is safe to remove for a deodexed ROM too
My point of stating odexed is that my tweaks can be used from the stock odexed ROM itself
Click to expand...
Click to collapse
oh ok, now I understand, thanks for this thread, very helpful indeed .
Awesome post thanks!
Not only for the tips but for teaching me a lot too!
Sent From My Android Shizzle!
thx dude!! awesomely useful!!
Great information thanks
Can you please include GPS tweaks as well?
awesomeandroid said:
oh ok, now I understand, thanks for this thread, very helpful indeed .
Click to expand...
Click to collapse
Thank you for reading it.
SkinBobUk said:
Awesome post thanks!
Not only for the tips but for teaching me a lot too!
Sent From My Android Shizzle!
Click to expand...
Click to collapse
It was my hope that it will give knowledge so that people could pass it on to more people
midikarma said:
thx dude!! awesomely useful!!
Click to expand...
Click to collapse
Thank you
ajazz said:
Great information thanks
Can you please include GPS tweaks as well?
Click to expand...
Click to collapse
Thank you for reading it What kind of GPS tweaks? There are a few notable ones. The most useful ones are disabling AGPS as well as updating the gps.conf. Do you mean that?
Oh man... Thx for your work... This thread is very useful.
I take my hat off.
Sent from nobody knows where
Wonderful job, pikachu01! A new user will need weeks, maybe months to gather all the bits of info you put here, served on a silver platter! Thank you veeeery much.
Mods, this should be stickied!
demonstone said:
Oh man... Thx for your work... This thread is very useful.
I take my hat off.
Sent from nobody knows where
Click to expand...
Click to collapse
Thank you
ZioGTS said:
Wonderful job, pikachu01! A new user will need weeks, maybe months to gather all the bits of info you put here, served on a silver platter! Thank you veeeery much.
Mods, this should be stickied!
Click to expand...
Click to collapse
Thank you Zio I forgot to add a few more posts to reserve. I guess I will add links if I do have any other things to add
Indeed lots of good info here for people just starting out, and some for people like me who've been around the block once or twice too!
I figured out how to do the CSC change myself, I just put the BMC folder from stock ROM into /system/csc and used one off the CSC selector apps from the market. Is this much different from the instructions here?
Since this has brought up the topic of freezing apps I will ask a question here if I may: Is there a way to keep apps from starting services, without getting rid of them? For example I use Skype and Facebook but I don't want their services running all of the time sucking up memory. Also I notice now that I game I installed recently (E Warriors) is running a service! WTF this is out of control. Any ideas?
haloimplant said:
Indeed lots of good info here for people just starting out, and some for people like me who've been around the block once or twice too!
I figured out how to do the CSC change myself, I just put the BMC folder from stock ROM into /system/csc and used one off the CSC selector apps from the market. Is this much different from the instructions here?
Since this has brought up the topic of freezing apps I will ask a question here if I may: Is there a way to keep apps from starting services, without getting rid of them? For example I use Skype and Facebook but I don't want their services running all of the time sucking up memory. Also I notice now that I game I installed recently (E Warriors) is running a service! WTF this is out of control. Any ideas?
Click to expand...
Click to collapse
Yes, the CSC instruction does the same thing. I'm just a bit thorough sometimes
You could use System Tuner or Titanium Backup Pro to freeze the app and then unfreeze it when you want to use it. Freezing is actually just doing a PM disable. PM disable basically makes Android think that the app is gone when it's actually still there. Unfreezing an app is basically just 1 click, hence its hassle free.
ZioGTS said:
Wonderful job, pikachu01!
Mods, this should be stickied!
Click to expand...
Click to collapse
Agreed +1
Excellent & informative
Awsome post pika.. Great work.. thx
Very nice tutorial. Should be pinned
Sticky please (with sgs chlorine).
Great work, much appreciated.
Sent from my Galaxy S using XDA Premium App
pikachu01 said:
Thank you for reading it.
It was my hope that it will give knowledge so that people could pass it on to more people
Thank you
Thank you for reading it What kind of GPS tweaks? There are a few notable ones. The most useful ones are disabling AGPS as well as updating the gps.conf. Do you mean that?
Click to expand...
Click to collapse
I have tried lot of Roms and none gave me satisfactory GPS performance except InnOvaTioN v2 by bezke,this Rom gave me almost instantaneous gps lock , when under partial cover it took a minute or so !
Then i moved on to v3 and was back to square one!
unfortunately v2 is no longer available for download.
I have tried Faster Fix, Gps Aids, tried changing setting through sgs tools but no go.
even tried different modems.
ajazz said:
I have tried lot of Roms and none gave me satisfactory GPS performance except InnOvaTioN v2 by bezke,this Rom gave me almost instantaneous gps lock , when under partial cover it took a minute or so !
Then i moved on to v3 and was back to square one!
unfortunately v2 is no longer available for download.
I have tried Faster Fix, Gps Aids, tried changing setting through sgs tools but no go.
even tried different modems.
Click to expand...
Click to collapse
well, then open a thread on general, Q&A, etc.
and let someone upload it
hopefully there are still copys of it out there
so there's a way to analyze and understand what was done to get those great results
@pikachu01:
great work on collecting all of this information & putting it in a central place !
*subscribes*
+1 for sticky
Very nice guide. It'll be very helpful for begginers. +1 for the idea to stick it
Welcome to Lightning ROM
MAJOR UPDATE, REV3, CHANG LOG IN SECOND POST**********
The goal when creating this today has been simple. Squeezing the most performance out of the T-Mobile Galaxy S III as I possibly could, without destroying your battery. This ROM was build with two things in mind - optimization and speed. Nuff said. It is based off the official Jelly Bean leak as of late last night and wild child's deodexed version he was kind enough to throw down. It will probably impregnate you, with twins, then not pay you child support. If you are ready to propel your device to levels above 9 thousand, you should probably keep reading. You have been warned. IT IS FAST! ..... yet... friendly...
Like myself, in the spirit of android, I am sure you all love customization. I am doing something a little different with this. Rather than add all the toggles, mods, themes, etc, I focused today on the performance aspect and will leave the theming up to you, and after you get it set up the way you want (as there will soon be and already is tons of pretty extras for this build) revert to post 2 of this thread for a nice little guide to odex this bad boy straight from Android UI via terminal emulator. I'll take care of the tweaking, you theme it the way you want, then wrap it up with some memory optimization of your own, or don't. Sound good? Thought so
Getting right down to it - a quick list of things modified here, and I know I am missing some things:
-Init.d support
-Busybox
-Deodexed (until you odex - see post 2)
-Rooted - duh
-CIQ removed***
-Debloated: removed a lot of stuff, but it is all avail' in the market, youtube, etc, you would have had to update it anyways -__-
-File system and SD read optimized for speed
-added freeza's custom CPU script to init.d ***see changelog in post 2
-Build.prop has been modified.
*added the 0 ring delay script
*wifi scan adjusted to 600
*media streaming optimized
*media recording optimized (video and image)
*data speeds optimized
-Database df on each boot / sql support - totally kanged this from somewhere else it was kanged... all credits due
-Memory optimizations
-Default IO scheduler optimized for flash-type disks (android devices)
-Carefully modified CPU parameters with performance in mind. Tweaked values to optimize IO throughput during heavy workload and multi-tasking, yet on the other end, CPU cycles are greatly reduced when system is not under heavy load. You will see this in performance :highfive:
INSTALLATION - follow this to the T, or I will ignore you. And keep in mind you might still have issues. Not every device is the same.
1. download ROM, put it on your external SD card, and verify it is good with an MD5 check
2. once all is well, boot to recovery
3. do a factory reset/data wipe (I have always been in the habit of being thorough and formatting anything 3 times)
4. format/wipe system (3 times recommended)
5. flash ROM
6. reboot (it will take a couple minutes)
7. once the device boots, let it stand alone for about a minute or so (i typically wait until it shuts off the display on its own) and ENJOY
NOTE: DO NOT TRY TO SIGN IN TO DROP BOX. I REMOVED IT. DL FROM MARKET!!
Also, some other things removed: browser, YouTube, calculator, some other stuff. I didn't remove anything that was not available in the play store. Wanted to keep it light weight. Do not try to sign in to anything other than your google account when you boot. Again, enjoy.
thanks to wild child, freeza, virus, steelH, dj, luke, ktoonz, and many others. mad respect to you all. i have implemented things that are either your direct work or things i have learned from you. so here is my humble shout out. if there is something i left out, somebody i didn't mention, please forgive me and post in this thread and call me out, i will happily update the OP with thanks. respect to you all
REV_3 - ready, set.. ok click now!
With morfic's kernel..... clocked at 1.83
ok... so if you are like me, and you REALLY wanna get intense with this, and just make it as bad A as you possibly can, keep reading....
This will essentially odex all files in your /system/framework and it will do it straight from the Android UI via my personal favorite app ... this is good because it frees up mem, and reduces DVM size. OPTIMALLL
1. download the odex.zip here --> PURPLE
2. extract all files with a file explorer, i prefer root explorer or fx file explorer
3. place the extracted folder and all of it's contents in /data/local/tmp ... so you should have /data/local/tmp/odex/+(misc files in new odex directory)
4. give the new directory and ALL contents FULL permissions. full read, write, and execute perms. your file explorer, if it has taken you this far, should be able to accomplish this
5. download this app TERMINAL EMULATOR dont worry it is free. open the app
Type the following commands - each new line should be executed with the enter key:
su (hit enter, it will ask for root)
/data/local/tmp/odex/odex (hit enter, you will see
you will see a bunch of outputs. there will be a message when it is done (honestly, like 10 seconds if that) saying something like "enjoy your hybrid ROM"
type "reboot recovery" (without the quotes)
device will boot into recovery immediately after you hit enter...
wipe cache and dalvik cache once more each, and reboot your device.
viola <--- this was spelled wrong. but i am going to leave it. because i can. rofl
THANKS*** freeza for sending me the the odex script, and you're welcome, for the bootclasspath for the script.. lulz. and thanks freeza for convincing me to download titanium backup again... and you're welcome for giving you the peace of mind that you can odex framework from android. el o el
****change log*****
rev3-December 1st, 2012 -uploading
-added morfic's alpha 23 kernel. OC'able to 1.83, no UV, L2 cache tables optimized, CPU hot plugged (for now, panel of=cpu1 off), pretty much an overhaul here. performance is ridiculous.
-removed CPU tweak by freeza (i still love you tho)
-optimized IO, AGAIN. adjusted ondemand parameters for a little bit better performance
-removed unneeded scripts from init.qcom.post_boot.sh file - positive effect on IO
-cleaned up build prop, added scripts for TCP windows, added network hack by... somebody... can't remember. File is in /etc/init.d/ "internet"
-optimized BT audio streaming
-added properties for optimal accessibility of T-Mos spectrum/towers
-disabled unneeded logging - save CPU cycles and power
-debloated some more. lightweight. DO NOT... try to sign in to dropbox upon first boot (if it even gives you the option) download the latest version of the app on the play store.
rev2-NOVEMBER 19, 2012
-removed some UI audio sounds (charger connection [for those that listen to music], lowbattery sound, volume toggle sounds, other annoying useless sounds such as boot up and power off)
implemented freeza's CPU control script for some amazing performance and battery life. thanks bud, as always, great work. i have been running this since he was finished with it, and it is absolutely amazing. your device with tons of unique and user friendly, editable scripts.
-freeza's CPU script adjusts CPU parameters for both cores based upon whether your device is charging, and how much battery you have left. it is a performance and battery friendly script that is power efficient and editable depending on what YOU want your device to do.
beta1-
initial release
all the things...
In rev 2, with freeza's CPU mod, you can navigate to init.d and you will see a "70cputweak" file. if you open that up, you can adjust CPU values and parameters of governors to your liking. for now, i left them as is - the way they were when freeza gave them to me. edit them with a file explorer and reboot and you are now adjusting your OWN values based on the performance and battery YOU desire. follow instruction in OP to flash
Thanks will try this later today
Sent from my SGH-T999 using xda app-developers app
Does teathering work on this?
ScottBroker said:
Does teathering work on this?
Click to expand...
Click to collapse
wireless/native? no. but my easy tether app works perfectly. i'll implement it, if i have time, in beta2... i haven't slept in two days lol
OP updated
Will the odex.me app work with this rom? I'm not lazy, just curious if there's an easier way to odex..tia
Sent from my SGH-T999 using Xparent Blue Tapatalk 2
Yeah does the odex me app work the same way than doing all that other stuff?
Sent from my SGH-T999
which tether app you using ?
Thanks
Odex me app will not work
great Rom thanks
Is this still running Touchwiz? How much RAM available? Other then your optimizations for speed what has been added or removed? Are animations gone due to the optimizations?
EGBTMagus said:
Is this still running Touchwiz? How much RAM available? Other then your optimizations for speed what has been added or removed? Are animations gone due to the optimizations?
Click to expand...
Click to collapse
All I have done is tweak properties listed. Didn't mess with animations, or anything. You guys can do all that with a theme, kitchen, etc... I would recommend wild child's work. It's great stuff. Like I said the reason for this is because after you get it the way you want, you can go in and odex it and finalize your OWN build the way you want it to look. I'm not too big on aesthetics. But I can make your device run better
And to answer your question, yes, it is still running touchwiz launcher by default. Again I would recommend apex or nova. touchwiz is awful IMO. nothing unique about it.
Rom looks great will be testing it tonight!
Can anyone confirm wildchilds kitchen is working?
Sent from my SGH-T999 using xda app-developers app
Liking the rom so far, only issue I have come across is that I can't get App2ExtSD2 working.
Can we use your Odex wizardry in any deodexed TW Rom?
SiNJiN76 said:
Can we use your Odex wizardry in any deodexed TW Rom?
Click to expand...
Click to collapse
yeah
http://forum.xda-developers.com/showthread.php?t=1994048
Thanks...didn't know he created a separate thread.
Anyway, the first thing I noticed was that when I try to sign into Drop Box from the initial boot sequence, it FCs... I also got nowhere near the Quad score the OP got. Mine was in the 3Ks. Just my experience.
CIQ?
SiNJiN76 said:
Thanks...didn't know he created a separate thread.
Anyway, the first thing I noticed was that when I try to sign into Drop Box from the initial boot sequence, it FCs... I also got nowhere near the Quad score the OP got. Mine was in the 3Ks. Just my experience.
Click to expand...
Click to collapse
I got over 5K in Quadrant, but I also came from a 100% stock phone (reset it to make sure there were no issues). DropBox fails intially because he removed dropbox from the rom.
EDIT:
I can't seem to find the stock web browser... has it been removed?
As the title state. And please get it together & keep it clean, as this is kinda important to all.
Any help & explaination would be much apprecited.
Regards,
Sdojoin
I used to mess wit this on the X10, and did find better values. But for the Xperia Play, at least on CM10, any extra or changed flags either causes worse performance or FC's.
The defaults I use are:
Code:
dalvik.vm.dexopt-flags=m=y
Which means "Map registration = yes" (this should always be on) and everything else at default (what the ROM wants to do).
90% of what you need to know (and what is safe to experiment with) can be found in the DalvikVM documentation. Give it a good read.
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Thanks. But i was wondering if mybe we can "force" the system/rom to optimize the dalvik.vm each time we use it.
Example;
Code:
dalvik.vm.dexopt-flag=o=y,m=y(optimize=yes, register map=yes)
Or
Code:
dalvik.vm.dexopt-flag=o=v,m=y(optimize=verify,register map=yes)
Will it make any diff?? I know it'll use more ram than usual, but will it increase performence??
Regards,
Sdojoin
o=v (-Xdexopt:verified) is the default, as is v=a (-Xverify:all). This means that only opts that are verified will be optimized (cached to dex files). Unverified code will not be optimized.
Disabling verification will make dalvik-generation faster, but it is less safe and also 0% faster once the dalvik-cache is generated. Apparently it has the possibility of decreasing RAM usage at the expense of higher IO or CPU cycles (which wouldn't be bad, since RAM is the main limiting hardware on Xperia 2011 devices) but I never noticed any difference.
The only real change you can make there is o=a, which means that it will optimize *all* dalvik opts - even those that fail verification. In the case of custom ROM's, this usually results in constant FC's and even reboots - and can even make the system slower because some classes are intentionally made to fail verification when, in the development process that they were found to have overhead in dalvik-cache reading making the unverified cache slower than just reading reading the dalvik (compiled Java code) directly. This is usually the case with simple Java methods that are heavily dynamic and rarely used (e.g. on a service startup).
Another option can be v=n o=a which means to verify nothing and optimize everything (potentially the fastest but also unsafest).
With all this said, I have not tried messing with these things since Gingerbread. All I can say is, experiment with these flags. Measure the size of dalvik-cache, the time it takes to generate, and the time it takes to load a large dalvik app (look for an app/game that has a very large DEX file in dalvik-cache, measure different parts of the app/game loading sections since some parts might be native instead of dalvik/java).
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
How exactly do i do that test??
Fyi, i already tried the v=n,o=a sett. It kinda denied su perm or mybe unroot my device. Coz i cant get any root app running & i hav to revert it back via flashable .zip. But like u said, its un-safe to use.
In-conclusion, "it can increase our perf & decrease it at the same time.". Erm...
Oh yeah, is it posible if i were to flag it like this??
Code:
dalvik.vm.dexopt-flag=m=o=y(map registration=Xdexopt=yes)
Just curious.
Regards,
Sdojoin
sdojoin said:
How exactly do i do that test??
Fyi, i already tried the v=n,o=a sett. It kinda denied su perm or mybe unroot my device. Coz i cant get any root app running & i hav to revert it back via flashable .zip. But like u said, its un-safe to use.
In-conclusion, "it can increase our perf & decrease it at the same time.". Erm...
Oh yeah, is it posible if i were to flag it like this??
Code:
dalvik.vm.dexopt-flag=m=o=y(map registration=Xdexopt=yes)
Just curious.
Regards,
Sdojoin
Click to expand...
Click to collapse
Nah, that makes no sense.
Read through this thread: http://forum.xda-developers.com/showthread.php?t=1622433
CosmicDan said:
Nah, that makes no sense.
Read through this thread: http://forum.xda-developers.com/showthread.php?t=1622433
Click to expand...
Click to collapse
Already read that actually.. I've already search & read through the web bout this still cant find any straight answer bout this. But then again there aren't any straight answer bout this, is there??
Another thing i would like to ask is bout vm.heapsize. Correct me if i'm wrong, the default value for all device is 32m, right?? And all my search state that 48m is the best value for both batt drain & perf. What do u think of that?? I really believe Play can do more & perform better in any case of situation. Dont matter either on stock or custom. Just need the right tweakin'.:fingers-crossed:
Well that first link I posted explains pretty much everything about the dalvik flags, and that thread I posted last is a good experiment for learning purposes. If it doesn't make sense I guess you need to know more about the Android technicals. But really, I think you can't wrap your head around it for one simple reason - there is no magical dalvik setting that will make the device faster. There is no "hidden setting" or "something Sony/FXP forgot to try" - the dalvik settings are fine, and while changing them may slightly increase performance in *some* cases, it will almost always reduce reliable and performance in other cases.
About dalvik heapsize:
The dalvik.vm.heapgrowthlimit property limits how large an Android application’s heap can get before garbage collection has to be attempted. The dalvik.vm.heapsize property defines an absolute maximum for the heap size for an application even when the largeHeap flag is set in the manifest. Google’s motivation behind doing this was clearly to limit the heap size to a reasonable amount for most applications, but also give some flexibility to app developers who know they’re going to need the largest heap size possible to run their application.
Should you change this setting? Probably not. The ICS default for a phone with (at least) 1024MB of RAM is 64m. You can check your specific phone’s value as the hardware vendor can override this themselves when they build the ROM. But don’t let the disparity between 1024 and 64 bother you; most mobile apps should not have any problems with 64MB of heap size unless the developers are naughty. When this limit is reached, a garbage collection routine will remove obsolete objects from memory reducing the heap size down considerably in most cases. It is extremely unlikely raising this value to reduce GC routines will have any perceptible effect. If anything, it could cause other apps or the general system to suffer from too many stale objects sulking around in memory. Garbage collection will inevitably occur either way, and when it does, the size of the heap will likely have a direct impact on the cost of the routine.
The point is, it is impossible for a user to optimize for every application using this system-wide setting. This responsibility falls on application developers to optimize their applications, not users. The largeHeap flag was created to allow developers to do just that. If you do feel compelled to experiment with this setting regardless, be mindful that an application could have up to two heaps at once. Thus, the heap growth limit value should always be, at most, a little less than half of the maximum allowable heap size.
Click to expand...
Click to collapse
In summary - heapsize = memory an app can consume before Android starts cleaning/pruning the app's memory for data that isn't in use. Lowering it to e.g. 40m can increase performance a bit but some games fail to load (because the OS starts GC when the app has not finished using the heap it requires; and also because so many game developers out there are lazy and don't do threaded asset loading properly)
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Hmm... Quite a mouthfull. Imma try & digest it slowly just so i could grasp everything properly.
A side Q, the 40m example u gav, does that really help?? I'm on GB btw. Only went to ics or jb when i got free time to test.
Do u recommend that example to be use or do u hav any other recommendation that would probably help me & other that read this thread??
Regards,
Sdojoin
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Experiment and see as long as you make backups, nothing can possiblii go wrong.
Sent from Xperia Play (R800a) with Tapatalk
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Right on. Thanks for ur time & for sharing ur experience & everything.
Salute.
Regards,
Sdojoin
No problem. Let me know if you find anything interesting. But you are on GB and I'm on JB, still I don't have much time to mess with this stuff - especially now that my linux machine is back in action
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Woo.. Guess we can expect smething new from ya?? And i think i found smthing thats kinda weird or mybe interesting. After i disable the bytecode verifier, any heapsize that i put on build.prop dosent stick. And when i run this code on terminal,
Code:
getprop dalvik.vm.heapsize
It always came up with the same value. So i decided to use that value instead. I dont know if its the best value or not. But it does shows slight improvement. I havent try any games yet. Hopefully it perform a bit better than be4.
Regards,
Sdojoin
Hey,
These have seemed to improve performance (mainly boot time and app loading) on Gingerbread. They are set in new Turbo UI Classic ROM, give them a try.
Code:
# was m=y
dalvik.vm.dexopt-flags=m=y,v=n,o=v,u=n
TBH, I really don't know a lot about how the dalvik flags tie together. But this seems to work well and stable.
CosmicDan said:
Well that first link I posted explains pretty much everything about the dalvik flags, and that thread I posted last is a good experiment for learning purposes. If it doesn't make sense I guess you need to know more about the Android technicals. But really, I think you can't wrap your head around it for one simple reason - there is no magical dalvik setting that will make the device faster. There is no "hidden setting" or "something Sony/FXP forgot to try" - the dalvik settings are fine, and while changing them may slightly increase performance in *some* cases, it will almost always reduce reliable and performance in other cases.
About dalvik heapsize:
In summary - heapsize = memory an app can consume before Android starts cleaning/pruning the app's memory for data that isn't in use. Lowering it to e.g. 40m can increase performance a bit but some games fail to load (because the OS starts GC when the app has not finished using the heap it requires; and also because so many game developers out there are lazy and don't do threaded asset loading properly)
Click to expand...
Click to collapse
Ther is one thing i don't understand: the default values of the Nexus 7 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=384m
Especially the heapsize seems to be very high.
The defauklt settings of my Galaxy Note with CM10.1 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
So they are much lower values. Bothe devices have 1Gb of Ram.
Some people say higher=better, some say lower=better and I'm really confused now.
What are the "perfect" values for the Galaxy note (1GB Ram) or Note 2 (2GB Ram) ?
I hope somone can explain me these things :fingers-crossed:
xxLeoxx93 said:
Ther is one thing i don't understand: the default values of the Nexus 7 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=384m
Especially the heapsize seems to be very high.
The defauklt settings of my Galaxy Note with CM10.1 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
So they are much lower values. Bothe devices have 1Gb of Ram.
Some people say higher=better, some say lower=better and I'm really confused now.
What are the "perfect" values for the Galaxy note (1GB Ram) or Note 2 (2GB Ram) ?
I hope somone can explain me these things :fingers-crossed:
Click to expand...
Click to collapse
There never exist "perfect values for dalvik".
It is how you want to allocate memory.
1. VM Heap Size is max Memory per one ram heal that can be given to an app.
2. Heapstartsize is the minimum size for a dalvik ram heap.
3. HeapGrowthLimit is a value for "normal" VM heaps, I reccomend setting VM heap size large and then HeapGrowthLimit at a good value.
Sent from my GT-I9300 using xda app-developers app
CosmicDan said:
Hey,
These have seemed to improve performance (mainly boot time and app loading) on Gingerbread. They are set in new Turbo UI Classic ROM, give them a try.
Code:
# was m=y
dalvik.vm.dexopt-flags=m=y,v=n,o=v,u=n
TBH, I really don't know a lot about how the dalvik flags tie together. But this seems to work well and stable.
Click to expand...
Click to collapse
Already tried n went back to m=y. It kinda hung up on some app that make'em fc. A diff sequence mybe??
Regards,
Sdojoin
sewer56lol said:
There never exist "perfect values for dalvik".
It is how you want to allocate memory.
1. VM Heap Size is max Memory per one ram heal that can be given to an app.
2. Heapstartsize is the minimum size for a dalvik ram heap.
3. HeapGrowthLimit is a value for "normal" VM heaps, I reccomend setting VM heap size large and then HeapGrowthLimit at a good value.
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
No it's not. All the heapsize parameters are to do with GC, they have nothing to do with "how much memory" dalvik tasks will use but determine barriers/zones for garbage collection.
Besides, if you read the therad you'd see that this has nothing to do with what we're talking about. We're talking on *flags*, heap parameters should NEVER be changed and will only make device unreliable.
EDIT: Read documentation before repeating what others say on the internet - http://show.docjava.com/posterous/file/2012/12/10222640-The_Dalvik_Virtual_Machine.pdf
sdojoin said:
Already tried n went back to m=y. It kinda hung up on some app that make'em fc. A diff sequence mybe??
Regards,
Sdojoin
Click to expand...
Click to collapse
Hmm fair enough. Well I've only ever seen m=y on any ROM, stock or custom or otherwise (as long as it hasn't been screwed up by some idiot chef). So maybe it's just a case as most so-called tweaks - what it comes with is what it's designed to work with.
Perhaps with the Qualcomm-accelerated Dalvik blobs (I posted it a while back, check my threads) there will be different results.
sdojoin said:
Already tried n went back to m=y. It kinda hung up on some app that make'em fc. A diff sequence mybe??
Regards,
Sdojoin
Click to expand...
Click to collapse
have you delete dalvikcache and reboot on every change?
mpjoe2000 said:
have you delete dalvikcache and reboot on every change?
Click to expand...
Click to collapse
Same.. Thats y its weird.
@CosmicDan - can u giv the thread link?? Thx
Regards,
Sdojoin
Left for posterity, but no further development will occur (see 4/30/2020 post)...
Here's a script that I helped some good guys out with developing "back in the day" (Franco's Dev Team - you can look them up!). Actually, it is a trimmed, consolidated version of the set-of-scripts we came up with. If you search, you can find osm0sis still hosts the original files, and those that I have been maintaining since the Galaxy Nexus went extinct (through L, M, N, and now O), I believe. Note that those scripts will no longer on Android 10 - and probably not even on 9 - so I don't recommend actually using them.
This script has all of the original tuning scripts put into a single file, having stripped out anything that stopped working between Kit-Kat and Android 10 (which was substantial), and some very small improvements I've found over the years. I also added a few things more to my personal usage preference for this Pixel-2/XL version. It has also been trimmed to work on the Pixel 2 / Pixel 2 XL stock kernel whilst outputting no errors, on all android versions through Android 10, and now on Magisk 19.4+.
Notes:
- This script is lean and mean, but it's not rocket science.
- I didn't invent anything here. Feel free to use (or not), distribute, alter, whatever; to your satisfaction, giving credit for redistribution only to "Franco's Dev Team", and maybe me if you're feeling generous.
- Again, I have verified it works on my personal Pixel 2 XL, and is compatible with all Android versions, Kernels, and Magisk versions.
- It actually improves many benchmark scores (you know the usual culprits) without lowering any on my device. But, you know what that's worth (one device, only a few items likely significant on a statistical basis).
- It won't make your phone run any worse. It might even feel a bit "snappier", but YMMV.
- If you feel this script is good, bad, or does nothing, feel free to thank me - or hang me in effigy, as appropriate.
- I do not plan to do heavy maintenance on this, but I will keep it up to date so it at least safely runs on the Pixel 2 / 2XL as long as I own one. I will post updates with a minimal change log (it's a script, you can read it!).
Disclaimer:
I can't see how this could possibly cause irreparable harm to any android device on which it is run.
However, I suppose untested configurations may (rarely) have slow-downs, reboots, or other effects.
REGARDLESS, it is offered as-is with no warranty, and you choose to run this at your own risk.
Requirements:
Root
BusyBox installation (I recommend the Magisk module by osm0sis)
Knowledge of how to execute a linux script and/or where to place it / allow permissions to run on boot
Usage:
Download attachment to your device
Place file in /data/adb/service.d (for Magisk-rooted devices, using Magisk 18.0+)
remove ".txt" extension (leaving the .sh extension)
Ensure permissions are right (0755)
Reboot and wait 2 minutes
Credits:
Franco's Dev Team, esp. osm0sis
Google
Others as noted in the script file header
Change Log:
Version 34 (98pks34.sh):
Version added with no disabling of zram.
V33 is still active for those who don't need / want zram.
V33 generic is still active as well (V34 generic would be the same as generic version does not alter zram).
Version 33 (98pks33.sh):
- Updated with Franco Dev-Team tuned Deadline scheduler (still the fastest). Script uses this if Deadline is available in your scheduler, else it defaults to using Noop.
- Other very minor tweaks based on testing, and some code cleanup
Version 32 (98pks32.sh):
- Updated for Magisk 19.4 (primarily eliminated mounting calls on / and /system to prevent root interference or verity problems due to SAR implementation now standard)
- Backed off the schedutil governor performance tweaks just a bit, still more performance oriented then v30 and prior, just not as extreme
- Removed wakelock blocking (for now) for evaluation. Most kernels already block safe wakelocks anyway. If I find none of the benefits I'm looking for, I may add them back in the next release.
- Released corresponding device-generic version due to important Magisk / SAR compatibility updates
Version 31 (98pks31.sh):
- Simplified some VM settings / reverted to stock where no difference was noted
- Simplified some block IO parameters / reverted to stock where no difference was noted
- Increased transmission queue buffer based on latest testing (still lower than stock)
- Tuned Schedutil governor settings to bias for more performance, reduce lag
- Increase GPU min frequency to 342 MHz step (2nd from bottom) based on testing to reduce lag
- Note that these changes did not appreciably affect battery life in testing
- Simplified output file write-out
- Released official "generic device" companion script of this version for those asking
Version 30 (98pks30.sh):
! GOOD TO GO FOR Q-FINAL / A-10 !
- Re-enabled stock zram - was causing freezes after about 24-36 hours of uptime
- Re-enabled vm tweaks for increased battery life (disabled pdflush periodic writebacks, lowered potential for large data writes causing hang-ups as a result in dirty ratios, adjusted cache pressure to not favor dentry/inodes quite so hugely over pagecache)
- Blocked a few more known and safe-to-block wakelocks
Version 29 (98pks29.sh):
Reverted some changes that were causing some serious jank / freezes:
- Went back to noop
- Reintroduced periodic pdflush writeback (although less frequent than stock)
Version 28 (94pks28.sh):
Biggest changes in a while!
- Increased run delay to 2 minutes to stay out of kernel apps' way
- Reverted tcp_ecn to 2 (stock) for slight decrease in network latency
- Substantial vm tweaks for increased battery life (disabled pdflush periodic writebacks, lowered potential for large data writes causing hang-ups as a result in dirty ratios, adjusted cache pressure to not favor dentry/inodes quite so hugely over pagecache)
- Right-sized nr_requests for any scheduler (not just noop) relative to built-in Android queue-depth
- Changed scheduler to deadline* with Franco Dev Team's tuning tweaks (still fastest i/o I can manage in testing)
* Device-generic version (94pks28generic.sh) was left unchanged with noop scheduler
Version 27 (94pks27.sh):
- Fixed for Android Q while keeping backward compatibility with prior Android versions.
- Increased run delay to 90 seconds to stay out of magisk module or kernel apps' way.
Version 26 (94pks26.sh):
- Updated one minor (but hard to find), error in mount option filesystem tweaks that had been causing data connectivity issues on custom ROM's using this script or BlackenedMod.
- SPECIAL THANKS to @sublimaze for testing iterations until we found the root cause of this issue!
Version 25 - skipped, test versions for @sublimaze to help me figure out data connection issues.
Version 24 (94pks24.sh):
- Updated ext4 filesystem tweaks for even better battery life and performance
- Small reduction of entropy pool size based on other user feedback
Version 23 (94pks23.sh):
- Change header to list new Magisk 18.0+ late-start boot service folder location
- SEE ALSO OP FOR THIS LOCATION
Version 22 (94pks22.sh):
- Force read_ahead_kb to 1024 for faster I/O performance on all realistic file sizes
Version 21 (94pks21.sh):
- Increased load delay at boot back to 60s.
Version 20 (94pks20.sh):
- Added .sh extension to file to allow more flexibility for future tuning (now just delete .txt, but leave .sh in the file name before copying to run location)
- Slightly increased load time at boot to 40s to ensure script runs even for users with many magisk modules
- Reduced foreground app schedtune boost to 5% (was 10%) for battery saving when multiple apps are open with no perceived detriment to performance or app switching
- Increase dirty_expire and dirty_writeback timings for less overhead, reduced battery, and improved performance with no ill effects noted
- Reverted GPU min clock increase due to my testing finding the speed benefit was not noticeable but battery life was negatively affected
Version 19 (94pks19):
- Reduced load time at boot (enabled by re-ordering of script) to 30s
- tcp_ecn set to 1 for across-the-board network speed enhancement when handshake allows
- reduced txqueuelen to 128 for network speed enhancement on 4g/wifi (less bufferbloat)
- added wakelock blocker courtesy of @xFirefly93, but only for blocking wakelocks I have actually seen in BBS for Pixel 2 / XL.
Version 18 (94pks18):
- Increase cpu governor up-rate-time; VERY significant battery help with no performance degradation noticed.
- Reduce vm dirty ratio and dirty expires slightly to reduce potential (although unlikely) excess caching and latency from memory write-out.
- Slight code re-ordering for potential quicker boot delay in the future
Version 17 (94pks17):
- Schedtune code cleanup
- GPU min frequency set to 342 (performance boost with no adverse battery drain per @xFirefly93 testing)
- Increase cpu governor down rate limit by 25% for better performance with minimal battery life impact.
Version 16 (94pks16):
- Revert dir-notify-disable
- Fix a minor dirty-expire vm derp I made many, many releases ago
- Adjust dev/stune/schedtune parameters to ensure users won't have frequency scaling issues on any kernel, allowing cpu's to actually settle and sleep. This wasn't likely before, but is now virtually impossible, while performance improvement during app switching is still present!
Version 15 (94pks15):
- Fs dir-notify disable.
- Schedtune parameter tweaks for performance increase.
Credit: Both of the above were initiated by @xFirefly93, I only slightly modified the Schedtune parameters.
Version 14 (94pks14):
- Revert disabling service_locator, otg_wakelock, and debug kernel modules - no real battery save noted in testing; and I had some issues with apps hanging that required location services that were resolved by getting rid of this code.
- Change rq_affinity from 2 to 1 - I verified with I/O benchmark testing that this provides a slight increase in I/O performance, especially reads and sqlite operations. No battery life impact noted during days of testing.
Version 13 (94pks13): Internal test build - not released (probably would have been unlucky anyway )
Version 12 (94pks12):
- Turn off iostats - by popular request (slight battery save)
- Increase vm stat_interval to 60 - Thx to xFirefly93 (slight battery save)
- Disable service_locator, otg_wakelock, and debug kernel modules - Thx to xFirefly93 (slight battery save)
Version 11 (94pks11):
- Delay script start by 30 seconds for users with multiple late-start scripts or other Magisk modules
- Increase timer for vm dirty writeback (saves battery from less wake-ups, cache integrity still reasonably protected by low dirty background ratio)
- Slight kernel entropy increase
Version 10 (94pks10):
- Increase min_free_kbytes - better performance based on testing
- Reduce entropy read_wakeup_threshold - to prevent blocking apps or commands if entropy drops
- Thrift ipv4 / network settings that were ineffectual - cleanup with better or same performance based on testing
- Reduce scheduler nr_requests - less overhead, subjective latency reduction
- Revert to default read_ahead_kb - better performance based on testing
Version 9 (94pks9):
- Slight change-up on kernel entropy settings to keep pool about half-full.
- tcp_max_syn_backlog and tcp_ecn parameters added (thanks @Juzman for getting me to look at these!) that seem to help network throughput slightly - they certainly don't hurt.
- Added fstrim for data, cache, and system partitions at end of script - because why not do this on every boot?
Version 8 (94pks8):
New file location noted in header: /sbin/.core/img/.core/service.d
- Need to place script in this directory for Magisk 16.3 onward
- Backward compatible for previous versions back to 14.5
Script now executes 70% faster after boot
- Only sleeps for 30 seconds; verified to still run through Magisk late start service
Added file system optimizations for /system partition
Adjusted min_free_kbytes to 7 GB from 7.5
- Should slightly raise available RAM for each node, no oom increase or other ill-effects verified through dmesg / kmesg logs
Reverted vm.vfs_cache_pressure to 20
- Less subjective latency based on testing
Script success / fail write-out file now time stamped for users local time rather than UTC/GMT
Version 7 (94pks7):
- Removed LMK (yay!) based on multiple requests, advice from @Scott, and my verifying that nothing I tried improved over stock.
- Added back in some block-level scheduler queue tweaks that are not consistent (and not optimized) on all blocks in the stock configuration as I thought they were
- Cleaned up and re-organized the code - inspiration from @Juzman
- Re-evaluated vm settings @Scott) and network tweaks @Juzman); I don't believe this resulted in any changes (except I'm trialing cache_pressure at 60 vice 20), but thanks for their advice, research, testing, and participation (which is also now credited in the script).
Version 6 (94pks6):
- Added feature: script now writes out a file "pks_script_result" to the /storage/emulated/0 (root of internal storage) directory when executed.
- If the file is present after attempting to run (or after a reboot if you have it in su.d, init.d, or service.d folders) then this indicates the script executed.
- If when you open the file in a text viewer it has a time/date stamp and the phrase "94pks6 successfully executed!", then it ran without errors.
- If when you open the file it says instead "94pks failed." then it threw some error code upon execution... but it was probably minor enough that the changes were applied (or the file wouldn't have been written ).
All the above is at least in theory. It seems to be working that way on my device. Thanks to @Scott for the suggestion!
Version 5 (94pks5):
- Lowered last lmk slot (empty apps) much further - no appreciable loss of available RAM during my testing, less redraws in chrome tabs and reloading of recent apps.
Version 4 (94pks4):
- Fixed aggressive Lowmemorykiller / memory over-commit interaction issue (only last LMK slot now much more aggressive than stock, vm.overcommit_memory reverted to "1" (stock). The interaction with previous settings could cause an issue where no additional apps could be opened (they were immediately killed).
- Very minor tweaks to some vm caching parameters
Version 3 (94pks3):
Corrected swap off command to not throw error flag on execution
Altered tx_queue_len replacement command to skip non-linked file and not flag error on execution
Thanks @Lessaj and @veetoe for helping
Version 2 (94pks2):
1). Increased LMK levels
---- I tested for weeks, we have gobs of RAM, it should really only affect empty apps
2). Turned off swap and de-allocated zram space
---- With 4GB of RAM, do we need zram? I don't think so. I found benchmarks and day-to-day performance to be slightly better without it, plus this is further enabled by increased LMK levels (in theory).
3). Reduced the vm dirty expire / writeback by a factor of 10 (still far more aggressive than stock)
---- No real effect here, just walking back to stock since I see no real effect with these parameters on Pixel 2.
4). Enabled Schedutil governor IO_wait_boost flag for both little and big clusters.
---- Should boost performance / reduce latency during high I/O events, found it to marginally increase some benchmarks and subjective performance feel without affecting battery (YMMV).
What if one doesn't have service.d in magisk?
Sent from my Pixel 2 XL using Tapatalk
I might give this a go in the morning. Add it and reboot in a full charge before I go to work. Using Flash kernel with my 2 XL, but hey, I'm always down for tweaking and tuning. I'll report back.
bryantjopplin said:
What if one doesn't have service.d in magisk?
Click to expand...
Click to collapse
You won't see it in the app. Use a root browser of some kind.
Root Partition/Magisk/.core/service.d
That would be the file path.
It wasn't there, just added it. Picture confirmed it was a folder
Sent from my Pixel 2 XL using Tapatalk
TheGeekyNimrod said:
I might give this a go in the morning. Add it and reboot in a full charge before I go to work. Using Flash kernel with my 2 XL, but hey, I'm always down for tweaking and tuning. I'll report back.
Click to expand...
Click to collapse
Should work fine with custom kernels... I'm just not sure if any of the tweaks might not already be in Flash - I know a couple aren't. Thanks for giving it a try and reporting back.
TheGeekyNimrod said:
You won't see it in the app. Use a root browser of some kind.
Root Partition/Magisk/.core/service.d
That would be the file path.
Click to expand...
Click to collapse
Thanks for helping others out while I was away!
bryantjopplin said:
It wasn't there, just added it. Picture confirmed it was a folder
Sent from my Pixel 2 XL using Tapatalk
Click to expand...
Click to collapse
That's truly odd - I've had 3 different devices with Magisk and they always had that folder. Could be that it was hidden to your file explorer of choice, especially since some of the folder names start with, or have "." in them? I dunno. Hopefully adding the folder manually like you did just works.
pkgnex said:
Should work fine with custom kernels... I'm just not sure if any of the tweaks might not already be in Flash - I know a couple aren't. Thanks for giving it a try and reporting back.
Thanks for helping others out while I was away!
That's truly odd - I've had 3 different devices with Magisk and they always had that folder. Could be that it was hidden to your file explorer of choice, especially since some of the folder names start with, or have "." in them? I dunno. Hopefully adding the folder manually like you did just works.
Click to expand...
Click to collapse
Using root explorer since OG Droid. Others are inferior imo. Thanks for checking up.
Sent from my Pixel 2 XL using Tapatalk
I had to show hidden files in Solid Explorer to see that folder! Thanks for the script!
Sent from my Pixel 2 XL using Tapatalk
bryantjopplin said:
Using root explorer since OG Droid. Others are inferior imo. Thanks for checking up.
Sent from my Pixel 2 XL using Tapatalk
Click to expand...
Click to collapse
Same one I use!
henderjr said:
I had to show hidden files in Solid Explorer to see that folder! Thanks for the script!
Sent from my Pixel 2 XL using Tapatalk
Click to expand...
Click to collapse
You're welcome.
Easy way to tell if the script is working? Or pretty much seeing this here is enough?
henderjr said:
Easy way to tell if the script is working? Or pretty much seeing this here is enough?
Click to expand...
Click to collapse
Which kernel are you running? If it's stock, the easiest way to tell for sure is to install a kernel editor (EX by FLAR2 is a good one, but there are others if you have to pay for that one, I forget) and see if some of the parameters in the script "took" like low memory killer values, vm parameters, entropy values, read-ahead kb, io-scheduler being noop instead of CFQ, etc. I know Flash uses cfq as the default sceduler, so if you're returning noop, that would indicate the script ran. I'm not sure what the default scheduler is on Despair's Snoke.
One thing - I don't think the folder you have it in is right. I think the path should be (root)/Magisk/.core/service.d NOT (root)/DEV/Magisk/IMG/.core/service.d
Just remembered, another way to see if it ran is to open Magisk manager, go into settings, click "log" and select the "Magisk" tab. You should see a bunch of stuff, but near the bottom you should see:
: ** late_start service mode running
: * Running service.d scripts
service.d: exec [94pks]
pkgnex said:
Which kernel are you running? If it's stock, the easiest way to tell for sure is to install a kernel editor (EX by FLAR2 is a good one, but there are others if you have to pay for that one, I forget) and see if some of the parameters in the script "took" like low memory killer values, vm parameters, entropy values, read-ahead kb, io-scheduler being noop instead of CFQ, etc. I know Flash uses cfq as the default sceduler, so if you're returning noop, that would indicate the script ran. I'm not sure what the default scheduler is on Despair's Snoke.
One thing - I don't think the folder you have it in is right. I think the path should be (root)/Magisk/.core/service.d NOT (root)/DEV/Magisk/IMG/.core/service.d
Just remembered, another way to see if it ran is to open Magisk manager, go into settings, click "log" and select the "Magisk" tab. You should see a bunch of stuff, but near the bottom you should see:
: ** late_start service mode running
: * Running service.d scripts
service.d: exec [94pks]
Click to expand...
Click to collapse
I'm stock 8.1 right now besides Magisk with Adaway.
The script is is in both places though I only remember putting it in one. Wonder if one is a copy of the other.
Anyway I see it in the logs so we should be good. Thanks again!
henderjr said:
I'm stock 8.1 right now besides Magisk with Adaway.
The script is is in both places though I only remember putting it in one. Wonder if one is a copy of the other.
Anyway I see it in the logs so we should be good. Thanks again!
Click to expand...
Click to collapse
One location is probably a sym-link to the other, then. Good to know!
I'm still running 8.0, so at least I now know it works on 8.1 as well.
On 8.1.0....
Seems??? To work. Little snappier
imaverik said:
On 8.1.0....
Seems??? To work. Little snappier
Click to expand...
Click to collapse
Thanks for the feedback! That's my experience as well.
These tunes/mods don't have as much of an effect as they used to, but I think they still offer a little improvement.
Any impact on battery,good or bad?
skinza said:
Any impact on battery,good or bad?
Click to expand...
Click to collapse
Should not affect battery at all, either way.
I guess in theory the faster network settings and io should mean you won't need your screen on as much, but any effect would not be noticeable.
So I've used the script alongside Flash Kernel beta and a few tweaks of my own. Can't really say I've noticed a battery difference as I also use Disable service and others. But I do feel there is a slight increase in response time whether it's touch, transition, fingerprint, etc.
pkgnex said:
Which kernel are you running? If it's stock, the easiest way to tell for sure is to install a kernel editor (EX by FLAR2 is a good one, but there are others if you have to pay for that one, I forget) and see if some of the parameters in the script "took" like low memory killer values, vm parameters, entropy values, read-ahead kb, io-scheduler being noop instead of CFQ, etc. I know Flash uses cfq as the default sceduler, so if you're returning noop, that would indicate the script ran. I'm not sure what the default scheduler is on Despair's Snoke.
One thing - I don't think the folder you have it in is right. I think the path should be (root)/Magisk/.core/service.d NOT (root)/DEV/Magisk/IMG/.core/service.d
Just remembered, another way to see if it ran is to open Magisk manager, go into settings, click "log" and select the "Magisk" tab. You should see a bunch of stuff, but near the bottom you should see:
: ** late_start service mode running
: * Running service.d scripts
service.d: exec [94pks]
Click to expand...
Click to collapse
Followed the above instructions
Ran no problem