Related
okay, so apparently SCEF02 FW users r stuck with video recording fps drop when recording in low light conditions (and no official solution from samsung yet)
more about the problem here:
http://forum.xda-developers.com/showthread.php?t=1443658
the only FW that seems to fix the problem is the SIEG03, which indicates that the problem is software related and CAN be fixed
however it disables flash in video recording mode & LED torch
so can't the devs figure a way to edit SIEG03 firmware to give us flash support?
links that may help (thanks bartekaki for providing it):
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
personally, I'll pay 10$ if it happens (or more if necessary)
who else???
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
suzaku said:
https://github.com/GalaxySII/samsung...a/video/m5mo.c
Click to expand...
Click to collapse
Dude, you can't even copy/paste links from others's posts...
I'll chip another 10$.
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
bartekaki said:
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
Click to expand...
Click to collapse
thx man
radkor said:
Dude, you can't even copy/paste links from others's posts...
Click to expand...
Click to collapse
I thought that since I linked to the original whole thread then it's ok...sorry I'll fix it
karendar said:
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
Click to expand...
Click to collapse
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
suzaku said:
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
Click to expand...
Click to collapse
SIEGE03 is a firmware. This firmware is required to run the camera... To access the camera functions, we need a driver. This driver is compiled from source code which is what the link above is...
What probably happened here is that the Infuse uses the same camera module and interface. The flash though might use a different register or address scheme in the source code of the Galaxy S2 to interface with the firmware. So someone would have to figure out the difference between the m5mo.c source code from the Galaxy S2 and the I997 to see if it can be fixed through driver. Otherwise we'd have to reverse engineer the firmware which is too much energy wasted.
The problem with this method is that we'll need to compile a new version of the camera driver. And that, I am not the person to do it.
Another solution would be to pull the camera driver from a stock I997's ROM and overwrite it on our phone to see if it works.
I got a galaxy s2 here last friday (coming from a htc desire), and this week i got around to using the camcorder function. Immediately noticed the stutter issue, checked the forums and the current firmware situation, and switched out my SCEF02 for the SIEG01. Of course it fixed the stutter but broke the flashlight, so i spent an evening looking into fixing it. Here's how far i got...
The firmware binary
First of all the SIEG01 firmware binary itself. I did a hex compare with SCEF02 and there are so many differences (hundreds when set to 16 byte difference comparison) it'd be almost impossible to find the incorrect memory address for the flashlight function control (at least in my limited ability).
Next up i tried looking for seperate sections within the firmware to frankenstein a fix. There was only one certain boundary i found with an identical address, that's around the 166FF area, where both files are padded with FF's to the same position (following is ASCII denoting the firmware version). That's a pretty clear indicator that it's a seperate part of the rom, so, i switched out the bottom half of SCEF02 into SIEG01. The result was no stutters, no flashlight. Likewise replacing the bottom half of SCEF02 with that of SIEG01 resulted in stutters and a working flashlight.
So in short, regarding the firmware itself, the section controlling the flashlight function is somewhere before 166FF in the binary. Everything in that first half of the firmware is reasonably similar between the two firmwares, but not identical. Mostly it's single byte changes (probably just the same variables stored in different addresses), and most of the similar sections are offset by roughly a word of data or more. I didn't spend hours looking through to discover where the extra words of data crept in though.
The driver
You could spend weeks tinkering with values within the first 1300KB of the binary trying to find the flashlight section alone, never mind the specific variable/register for the flashlight mode itself, so i moved on to checking the right values were being set by the driver (m5m0.c).
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
the relevant function appears to be m5mo_set_flash on line 858, and the function works pretty simply. First there's a case switch to set the values of two variables called flash and light which will be sent to the firmware. The final case is the one for the flashlight function, and needs flash to be -1 and light to 0x03:
Code:
case FLASH_MODE_TORCH:
light = 0x03;
flash = -1;
break;
If flash is less than 1 then no control command is sent to the firmware for the flash, so we can disregard that (i think). That just leaves the light function. i'll just quote the code here:
Code:
m5mo_writeb(sd, M5MO_CATEGORY_CAPPARM,
M5MO_CAPPARM_LIGHT_CTRL, light);
m5mo_writeb is the function sending (writing) the command to the firmware, sd i believe is the device itself, M5MO_CATEGORY_CAPPARM and M5MO_CAPPARM_LIGHT_CTRL are describing where to send the value of light to, on the device. I think it's safe to say M5MO_CATEGORY_CAPPARM is correct since the flash works fine and the same constant is used for the flash control code directly below the light code. It's also used for a bunch of other functions such as capture size etc.
In C code, variables that're defined in all uppercase are usually constants, so you need to go into m5m0.h to find the value for M5MO_CAPPARM_LIGHT_CTRL. line 272 will show you "#define M5MO_CAPPARM_LIGHT_CTRL 0x40". For the sake of being sure, line 180 also has "#define M5MO_CATEGORY_CAPPARM 0x0B".
Time to check out the Infuse source code and compare...
https://github.com/Entropy512/linux_kernel_sgh-i997r/tree/master/drivers/media/video
first of all m5m0.c, line 1411 you'll find m5m0_set_flash. The layout of the function is slightly different, it's still a switch case, but instead of using temporary variables to hold the values to send the flash and light, the values are just sent within the cases themselves. Anyhow, the light control section:
Code:
case FLASH_MODE_TORCH:
err = m5mo_writeb(client, M5MO_CATEGORY_CAPPARM, M5MO_CAPPARM_LIGHT_CTRL, 0x03);
CHECK_ERR(err);
break;
Again no command is sent to the flash, only the torch, and that value is 0x03 again. The same function and arguments are being sent as with the i9100 code earlier, so all that's left is to check the constants being used. Time to hop to m5mo.h for the infuse.
Line 183 "#define M5MO_CATEGORY_CAPPARM 0x0B" matches our i9100 driver. Line 282 "#define M5MO_CAPPARM_LIGHT_CTRL 0x40" matches our i9100.
Now there are some differences between the m5m0_set_flash functions and also in the m5m0_writeb functions for the two devices, but the values they're using to control the light are the same in both cases.
One thing of interest is that the infuse doesn't support autoflash which is light 0x04 and flash -1. However if you hook up the phone to your pc, run ADB and use the camcorder in low light or any flashlight apps, you can use dmesg to verify 0x03 is being sent, as the dmesg output will contain "m5m0_set_flash: E, value 0x03".
Essentially i think this rules out it being a driver issue. I mean i could be wrong, but it looks like the flashlight control values are identical for both devices. It seems like the issue is within the first section of the firmware binary, somewhere.
Hopefully this is of some use to anyone looking into a fix for the SIEG01 flashlight problem.
Thanks for share your investigation Myshkinbob. Very interesting.
I do believe is an "easy" firmware fix too.
As you did, i compared both firmwares binaries and took the hope for finding the flash part in the code. Without a reference there is too many unknown data for a trial and error. I mean i tried to copy-paste some code differences in the firmwares but no succes.
Since nothing looks broken i will keep trying...
It'd be good to get SGS II simulator on Windows. Without it, it's PITA to load every time APK into phone and reboot it to test one variable lol
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
wish i could help somehow...
Myshkinbob said:
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
Click to expand...
Click to collapse
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
suzaku said:
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
Click to expand...
Click to collapse
I'm pretty sure that's how samsung codes anyway, we're just lending them a hand in doing so. haha
how's it going guys? any news?
wish I could help but I'm a complete noob
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
blunted09 said:
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
Click to expand...
Click to collapse
Well this firmware really improves the overall quality of the pics but in shooting vids it really shines. Only thing so far missing is flash light during video capturing.
I would have moved to SIEG03 if it had had support of LED
me too, flashlight is a little bit to important for me
Most of the big performance boosts we've had lately have come from the Krait optimised Bionic library, and things like Linaro's strict aliasing patches (Linaro's compiler by itself makes nearly no difference, it really isn't the magic bullet a lot of so-called 'devs' are trying to give people the impression it is - my own builds have been done with Linaro's toolchain for a long time and it does nada by itself.)
However, it seems to me from watching the GIT repos of some of the more optimised ROMs appearing lately that developers are playing with various CFlags to try and optimise for this specific platform. As we know, there isn't a specific flag (either mtune or mcpu) for Krait:
Code:
Permissible names are: `arm2', `arm250', `arm3', `arm6', `arm60', `arm600', `arm610', `arm620', `arm7', `arm7m', `arm7d', `arm7dm', `arm7di', `arm7dmi', `arm70', `arm700', `arm700i', `arm710', `arm710c', `arm7100', `arm720', `arm7500', `arm7500fe', `arm7tdmi', `arm7tdmi-s', `arm710t', `arm720t', `arm740t', `strongarm', `strongarm110', `strongarm1100', `strongarm1110', `arm8', `arm810', `arm9', `arm9e', `arm920', `arm920t', `arm922t', `arm946e-s', `arm966e-s', `arm968e-s', `arm926ej-s', `arm940t', `arm9tdmi', `arm10tdmi', `arm1020t', `arm1026ej-s', `arm10e', `arm1020e', `arm1022e', `arm1136j-s', `arm1136jf-s', `mpcore', `mpcorenovfp', `arm1156t2-s', `arm1156t2f-s', `arm1176jz-s', `arm1176jzf-s', `cortex-a5', `cortex-a7', `cortex-a8', `cortex-a9', `cortex-a15', `cortex-r4', `cortex-r4f', `cortex-r5', `cortex-m4', `cortex-m3', `cortex-m1', `cortex-m0', `cortex-m0plus', `marvell-pj4', `xscale', `iwmmxt', `iwmmxt2', `ep9312', `fa526', `fa626', `fa606te', `fa626te', `fmp626', `fa726te'.
Krait supports vfpv4 and neon, so we should be using at least -mfpu=neon-vfpv4 on top of whatever cflags are currently thought best...
Somebody must have a Krait-based system that can run GCC4.6/4.7? - Rather than guessing, can't we take a look at what mtune/mcpu=native throws out on Krait? Or does 'native' not work on ARM?
For example: -march=native on my desktop gives me the following:
Code:
-march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=corei7-avx
I'd imagine this is all standard corei7-avx stuff, bar the cache sizes, but corei7-avx is pretty specific to a Sandy Bridge/Ivy Bridge-based system, whereas there is nothing specific to Krait.
If we really wanted to push the boat out, we could use acovea to see what the fastest specific flags are (although I guess you'd want to use different source to that acovea ships with as it's probably not too relevant to typical uses of an Android device )
Any thoughts on this matter? Am I just madly obsessed with things that make no difference? I'm going to put together some new AOKP PUB builds today since that's my favourite ROM but it would be interesting to have the insight of somebody who actually knows what they're talking about...
Azurael said:
Somebody must have a Krait-based system that can run GCC4.6/4.7? - Rather than guessing, can't we take a look at what mtune/mcpu=native throws out on Krait? Or does 'native' not work on ARM?
Click to expand...
Click to collapse
I asked the same question to myself.
Even made the toolchain at device (HTC One). (arm-gentoo based)
Tried various gcc, linaro's also.
Just one result: -mtls-dialect=gnu
Hi,
I'm just compiling my first Android kernel (for SM-P605) and have succeeded without any real issues. I just wanted to check whether some of the compilation warnings of the nature listed below are anything to be concerned abou:
Code:
1: Warning (reg_format): "reg" property in /soc/qcom,[email protected] has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
2: Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/[email protected]/[email protected]
I'm used to software development (it's a job and hobby) on Linux already and believe the second warning is nothing but, would just like to be sure and check with anyone experienced in Android Kernel compilation whether the first is worth paying attention to.
Thank you for taking the time to read. Should it get a green light, I'll probably do some further experimentation and make some releases (if there is any want for certain features from the community) after new year with some of the epic features that people are putting in to our brother devices.
Kind regards
Hi..thank you for creating kernel for the p605 as our community got very few developers. Is it possible for you to implement options to change governor, force charging, lmk settings to tweak around. Many thanks
Another "kernel optimizer"?
No. Well, yes. However, a "kernel optimizer" is a poor way to put it. KTweak performs kernel adjustments based on facts and evidence, unlike other optimizers with poorly written or heavily obfuscated code. For example:
LSpeed is almost 4000 lines long; completely unnecessary.
NFS Injector uses compiled binaries that are closed source... yuck. Not to mention the typos in the README. This one is hard to look at.
LKT sets random nonsensical build.props that likely don't even exist.
MAGNETAR uses (you guessed it) compiled binaries that install themselves to your /system/etc/ directory (???). Great idea, install an external closed source, compiled binary to the system partition.
Need I go on?
What's different about KTweak?
Unlike other "kernel optimizers", KTweak is:
Concice, at around 200 lines long,
Entirely open source with no compiled components,
Backed by logic and evidence,
Designed by an experienced kernel developer,
Non-intrusive, being completely systemless.
Benchmarks
The following benchmarks were performed on a OnePlus 7 Pro running the stock kernel provided by the OEM on Android 10.
hackbench -pTl 4000 (lower is better)
Without KTweak: ~20-50 seconds on average
With KTweak: ~4-6 seconds on average
perf bench mem memcpy (lower is better) (average of 50 iters)
Without KTweak: 14.01 ms
With KTweak: 10.40 ms
synthmark (voicemark) (higher is better)
Without KTweak: 374.94
With KTweak: 383.556
synthmark (latencymark little) (lower is better)
Without KTweak: 10
With KTweak: 10
synthmark (latencymark big) (lower is better)
Without KTweak: 12
With KTweak: 10
The Tweaks
In order to remain genuine, I have commited to explaining each and every kernel tweak that KTweak applies. Grab your coffee, this could take a while.
kernel.perf_cpu_time_max_percent: 25 --> 5
This is the maximum CPU time long perf event processing can take as a percentage. If this percentage is exceeded (meaning perf event processing used too much CPU time), the polling rate is throttled. This is reduced from 25% to 5%. We can afford inaccuracies with perf events in exchange for more time that a foreground task can use.
kernel.sched_autogroup_enabled: 0 --> 1
The Linux Kernel scheduler (CFS) distributes timeslices to each active task. For example, if the scheduling period is 10ms, and there are 5 tasks running, CFS will give each task 2ms of runtime for that scheduling cycle. However, this means that a SCHED_OTHER task may compete with a SCHED_FIFO task. Autogrouping groups task groups together during scheduling. For example, if the scheduling period is 10ms, and there are 6 SCHED_OTHER tasks running and 4 SCHED_FIFO tasks running, the SCHED_OTHER tasks will get 50% of the runtime and the SCHED_FIFO tasks will get the other 50%. For each task group, the timeslices are once again divided. The SCHED_FIFO tasks will get 12.5% runtime and the SCHED_OTHER tasks will get ~8.3% runtime. This usually offers better interactivity on multithreaded platforms. See scheduling priority documentation: https://man7.org/linux/man-pages/man7/sched.7.html See autogrouping off: https://www.youtube.com/watch?v=uk70SeGA7pg See autogrouping on: https://www.youtube.com/watch?v=prxInRdaNfc
kernel.sched_enable_thread_grouping: 0 --> 1
To my knowledge using the limited documentation of this tunable, this is basically autogrouping for thread groups.
kernel.sched_child_runs_first: 0 --> 1
When forking a child process from the parent, execute the child process before the parent process. This usually shaves down some latency on task initializations, since most of the time the child process is doing some form of heavy lifting.
kernel.sched_downmigrate: 20 20
Do not allow tasks to migrate back down to a lower-power CPU until the estimated CPU utilization would go below 20% on said CPU. This means tasks will stay on higher-performance CPUs for longer than usual.
kernel.sched_upmigrate: 80 80
Similar to the previous tunable, do not allow CPUs to migrate to the higher-performance CPUs unless the utilization goes above 80%.
kernel.sched_group_downmigrate: 20
The same as kernel.sched_downmigrate, except for whole task groups.
kernel.sched_group_upmigrate: 80
The same as kernel.sched_upmigrate, except for whole task groups.
kernel.sched_tunable_scaling: 0
This is more of a precaution than anything. Since the next few tunables will be scheduler timing related, we don't want the scheduler to scale our values for multiple CPUs, as we will be providing CPU-agnostic values.
kernel.sched_latency_ns: 10000000 (10ms)
Set the default scheduling period to 10ms. If this value is set too low, the scheduler will switch contexts too often, spending more time internally than executing the waiting tasks.
kernel.sched_min_granularity_ns: 1000000 (1ms)
Set the minimum task scheduling period to 1ms. With kernel.sched_latency_ns set to 1ms, this means that 10 tasks may execute within the 10ms scheduling period before we exceed it.
kernel.sched_migration_cost_ns: 500000 (0.5ms) --> 1000000 (1ms)
Increase the time that a task is considered to be cache hot. According to RedHat, increasing this tunable reduces the number of task migrations. This should reduce time spent balancing tasks and increase per-task performance. See RedHat: https://www.redhat.com/files/summit...tuning-of-Red-Hat-Enterprise-Linux-Part-1.pdf
kernel.sched_min_task_util_for_boost: 25
This value effects if tasks should be migrated to a higher performant CPU if it's utilization is above this amount. Allow tasks to be migrated upwards if the user is triggering a touch boost and the task is above 25% utilization.
kernel.sched_min_task_util_for_colocation: 50
This value is the same as the former, except it occurs when the user is not touching the screen. We shouldn't upmigrate tasks if the user isn't actively interacting with them (i.e. video streaming).
kernel.sched_nr_migrate: 32 --> 64
When migrating tasks between CPUs, allow the scheduler to migrate twice as many as usual. This should increase scheduling latency marginally, but increase the performance of SCHED_OTHER tasks.
kernel.sched_schedstats: 1 --> 0
Disable scheduler statistics accounting. This is just for debugging, but it adds overhead.
kernel.sched_wakeup_granularity_ns: 1000000 (1ms) --> 5000000 (5ms)
Require the current task to be surpassing the new task in vmruntime by 5ms instead of 1ms before preemption occurs. This should reduce jitter due to less frequent task interruptions.
kernel.timer_migration: 1 --> 0
Disable the migration of timers among CPUs. Usually, when a timer is created on one CPU, it would be able to be migrated to another CPU. However, this increases realtime latencies and scheduling interrupts. It can be turned off.
net.ipv4.tcp_ecn: 2 --> 1
Enable Explicit Congestion Notification for incoming and outgoing negotiations. This reduces packet losses.
net.ipv4.tcp_fastopen: 3
Enable data transmission during the SACK exchange point in TCP negotiation. This reduces packet latencies. Enable it for senders and receivers.
net.ipv4.tcp_syncookies: 1 --> 0
This tunable, when enabled, prevents denial of service attacks by allowing connection ACKs to be tracked. However, this is more-or-less unnecessary for a mobile device. It is more applicable for servers. Disable it.
net.ipv4.tcp_timestamps: 1 --> 0
RedHat claims that TCP timestamps may cause performance spikes due to time accounting code on high-performance connections. Disable it. See RedHat: https://access.redhat.com/documenta...ml/tuning_guide/reduce_tcp_performance_spikes
vm.compact_unevictable_allowed: 1 --> 0
Do not allow compaction of unevictable pages. With this set to 1, more compactions can happen at the cost of small page fault stalls. Turn this off to compact less but avoid aforementioned stalls.
vm.dirty_background_ratio: 5 --> 10
Start writing back dirty pages (pages that have been modified but not yet written to the disk) asynchronously at 10% memory dirtied instead of 5%. Writing dirty pages back too early can be inefficient and overutilize the storage device.
vm.dirty_ratio: 20 --> 30
This tunable is the same as the former, but it is the ceiling for synchronous dirty writeback, meaning all I/O will stall until all dirty pages are written out to the disk. We usually won't need to worry about hitting this value, as the background writeback can catch up before we reach 20% memory dirtied. But as a precaution (i.e. heavy file transfers), increase this value to a 30% ceiling to prevent visible system stalls. We are sacrificing available memory in exchange for a reduced change of a brief system stall.
vm.dirty_expire_centisecs: 300 (3s) --> 1000 (10s)
This is the longest that dirty pages can remain in the system before they are forcefully written out to the disk. By increasing this value, we can allow the dirty background writeback to take its time asynchronously, and avoid unnecessary writebacks that can clog the flusher thread.
vm.dirty_writeback_centisecs: 500 (5s) --> 0 (0s)
Do not periodically writeback data every 5 seconds. Instead, leave it to the dirty background writeback to wake up when the dirty memory of the system hits 10%. This allows the dirty pages to stay in memory for longer, possibly increasing cache locality as the page cache is still available in memory.
vm.extfrag_threshold: 500 --> 750
Compact memory more often, even if the memory allocation was estimated to be due to a low-memory status. This lets us put more data into RAM at the expense of running compation more often. This is a worthy tradeoff, as it reduces memory fragmentation, which is incredibly important for ZRAM.
vm.oom_dump_tasks: 1 --> 0
Do not dump debug information when (or if) we run out of memory. If we have a lot of tasks running, and are OOMing often, then this overhead can add up.
vm.page-cluster: 3 --> 0
Disable reading additional pages from the swap device (in most cases, ZRAM). This is the same philosophy as disabling readahead.
vm.reap_mem_on_sigkill: 0 --> 1
When we kill a task, clean its memory footprint to free up whatever amount of RAM it was consuming.
vm.stat_interval: 1 --> 10
Update /proc/stat information every 10 seconds instead of every second, reducing jitter on loaded systems.
vm.swappiness: 100 --> 80
Swap to ZRAM less often if we don't have to. ZRAM can become expensive due to constant compression and decompression. If we can keep some of the memory uncompressed in regular RAM, we can avoid that overhead.
vm.vfs_cache_pressure: 100 --> 200
This tunable controls the kernel's tendency to reclaim inodes and dentries over page cache. Inodes and dentries are information about file metadata and directory structures, while page cache is the actual cached contents of a file. By increasing this value to 200, we tell the kernel to prefer claiming inodes and dentries over the page cache, increasing the chance of a cache hit when referencing recently used data, while not polluting the RAM with less-important information.
Next Buddy
By scheduling the last woken task first, we can increase cache locality since that task is likely to touch the same data as before.
No Strict Skip Buddy
Usually, the scheduler will always choose to skip tasks that call yield(). However, these yeilding tasks may be of higher importance than the last or next buddy that are available. Do not always skip the skip buddy if we don't have to.
No Nontask Capacity
The scheduler decrements the perceived CPU capacity that longer the CPU has been idle for. This means that an idle CPU may be skipped during task placement, and a task can be grouped with a busier CPU. Disable this to improve task start latency.
TTWU Queue
Allow the scheduler to place tasks on their origin CPU, increasing cache locality if the CPU is non-local (i.e. a cache hit would definitely have been missed).
Governor Tweaks
hispeed_load: 90 --> 80: Jump to a higher frequency if we are approaching the end of the frequency list, where a task may begin to starve or begin to stutter.
hispeed_freq: : Set the "higher freq" (referencing hispeed_load) to the maximum frequency available to take advantage of Race-To-Idle.
CAF CPU Boost Tweaks
input_boost_freq: 1.4 GHz (closest freq) as a generic, universal boost frequency to the little cluster.
input_boost_ms: 250 ms, not consuming too much power but boosting for important, interactive events such as clicking on things.
I/O
iostats: 1 --> 0: Disable I/O statistics accounting, which adds overhead.
readahead: 0: Disable readahead, which is intended for disks with long seek times (HDD), whereas mobile devices use flash storage with zero seek time.
nr_requests: 128 --> 512: Allow more I/O requests to be issued before flushing the queue, slightly increasing latencies but allowing more requests to be executed before being put to sleep.
noop / none: Use a scheduler with little CPU overhead to reduce I/O latencies, which is essential for fast flash storage (eMMC & UFS).
ZRAM
ZRAM reduces disk wear by reducing disk writes, and also increases cache locality by allowing more data to fit in RAM at once. KTweak configures ZRAM to take up at most half of the available RAM on the system, which is a good ratio of RAM to ZRAM for a mobile device.
Other Notes
You should know that KTweak applies after 60s of uptime as to prevent Android's init from overwriting any values.
Contact
You can find me on telegram at @tytydraco. Feel free to email me at [email protected].
Downloads
All releases and the entire source code for KTweak is available on GitHub:
Downloads
XDA:DevDB Information
KTweak, Tool/Utility for all devices (see above for details)
Contributors
tytydraco, tytydraco
Source Code: https://github.com/tytydraco/ktweak
Version Information
Status: Stable
Current Stable Version: v1.0.7
Stable Release Date: 2020-08-16
Created 2020-08-16
Last Updated 2020-08-16
What are the requirements to use this? Root with Magisk is a given - but Linux kernel version, Android OS version, device, etc?
MishaalRahman said:
What are the requirements to use this? Root with Magisk is a given - but Linux kernel version, Android OS version, device, etc?
Click to expand...
Click to collapse
The script adjusts only the tweaks that are compatible with your version. It contains tweaks for EAS, HMP, and supports 3.18 and above in testing. It likely supports even lower. Otherwise, it's totally universal.
KTweak now has an official Telegram channel for release information and changelogs: @ktweak
Thank you for your work and great explanation ?
This will work on lineage kernel?
Hello there. Im using ver 1.0.9. I updated and tried 1.1.0 but ended up in reboots after boot complete. I am using NX kernel which seta vfs cache pressure to 100. May that be the case?
Now back to 1.0.9 and everything seems fine. However, I had to uninstall and reinstall magisk, because when Ive flashed 1.0.9 ober 1.1.0, I was still experiwncing problems.
lapirado said:
Thank you for your work and great explanation ?
This will work on lineage kernel?
Click to expand...
Click to collapse
This should work on any kernel
myaslioglu said:
Hello there. Im using ver 1.0.9. I updated and tried 1.1.0 but ended up in reboots after boot complete. I am using NX kernel which seta vfs cache pressure to 100. May that be the case?
Now back to 1.0.9 and everything seems fine. However, I had to uninstall and reinstall magisk, because when Ive flashed 1.0.9 ober 1.1.0, I was still experiwncing problems.
Click to expand...
Click to collapse
Hi! Thanks for the report. Which device and Android version are you using? I have an idea of why this could be happening.
myaslioglu said:
Hello there. Im using ver 1.0.9. I updated and tried 1.1.0 but ended up in reboots after boot complete. I am using NX kernel which seta vfs cache pressure to 100. May that be the case?
Now back to 1.0.9 and everything seems fine. However, I had to uninstall and reinstall magisk, because when Ive flashed 1.0.9 ober 1.1.0, I was still experiwncing problems.
Click to expand...
Click to collapse
Hi myaslioglu,
I've released v1.1.1 which adds an additional 20 second sleep after Android reports that it has been initialized. This should prevent init and any post-boot init scripts from running alongside ktweak. I believe your issue stems from ZRAM resizing itself alongside bootup, where memory is most scarce, possibly causing your device to think it failed to bootup correctly.
Please let me know if v1.1.1 fixes your issue. It is live on GitHub releases and Telegram.
tytydraco said:
Hi myaslioglu,
I've released v1.1.1 which adds an additional 20 second sleep after Android reports that it has been initialized. This should prevent init and any post-boot init scripts from running alongside ktweak. I believe your issue stems from ZRAM resizing itself alongside bootup, where memory is most scarce, possibly causing your device to think it failed to bootup correctly.
Please let me know if v1.1.1 fixes your issue. It is live on GitHub releases and Telegram.
Click to expand...
Click to collapse
Hello. Sorry I forgot to report my device, it is s8 exynos just in case. But 1.1.1 fixed the issue. Works perfect! Thanks
myaslioglu said:
Hello. Sorry I forgot to report my device, it is s8 exynos just in case. But 1.1.1 fixed the issue. Works perfect! Thanks
Click to expand...
Click to collapse
1.1.2 got me reboots again. What has changed? Only the swappiness? Worked fine on 1.1.1 and did not work on 1.1.0 as aforementioned.
Can zram be the issue?
1.1.1 made my op7pro freeze with weeb kernel ??* and we have the same device draco
Doesn't work on stock kernel of redmi note 9s, freezes a few seconds after boot,forcing me to hard restart
It compatible with j5 (2015)?
To those of you getting freezes, I have identified the cause to be related to ZRAM. I will push an update today that will remove ZRAM tweaking from the script.
The reason I believe this is happening is because ktweak tries to resize the ZRAM. That requires all data that is currently in ZRAM to decompress and enter your main memory unit. If we run out of memory during this process, we will freeze.
The solution is to not adjust the zram size when using ktweak. Sorry for the inconveniences that may have been caused. I'll get straight to fixing this as soon as possible.
I've heard about your work from xda Telegram channel.
I read the info and thought to test it, but as some users reported as latest update having freeze issue. I'll test with freeze issue fixed update.?
tytydraco said:
To those of you getting freezes, I have identified the cause to be related to ZRAM. I will push an update today that will remove ZRAM tweaking from the script.
The reason I believe this is happening is because ktweak tries to resize the ZRAM. That requires all data that is currently in ZRAM to decompress and enter your main memory unit. If we run out of memory during this process, we will freeze.
The solution is to not adjust the zram size when using ktweak. Sorry for the inconveniences that may have been caused. I'll get straight to fixing this as soon as possible.
Click to expand...
Click to collapse
I ever disabled ZRAM on my OP7 PRO feels more fluid
Is working on mi 10 pro?
Vivo v9
How can I root vivo v9 1723?
I tried many methods but nothing work for me.
Please help
tyagis777 said:
How can I root vivo v9 1723?
I tried many methods but nothing work for me.
Please help
Click to expand...
Click to collapse
Really? You created an account for this post?
Hi, there
EAS kernel (mainly Energy Aware Scheduler) was firstly proposed by ARM few years ago and nowadays used more widely in custom ROM, although the OEMs didn't support it. The main obstacle of developing EAS kernel is the busy-cost-data for a specified CPU. Fortunately, Pixel 2 uses the same CPU as our XiaoMi 6 and Google shared the data in AOSP. Developers can directly use it for sagit. But EAS is not just a piece of data, we need drivers to make it work better for us.
The CPU scheduler supported in EAS is the famous /schedutil/ governor. This governor is unique and very different from others that it handles the frequencies based on system load. In our sagit kernel, there are already WALT (Window Assistant) codes left by Codeaurora, which can be used to predict the system load. So far, everything seems ready except of boosting things.
SchedTune was born for that. It creates 5 cgoups for different kinds of tasks, one of which is the /top-app/. Settings for this group will significantly affect the user experience. However, AFAIK, there are still no applications in userspace to control the interface, aka /schedtune.boost/. Its value can be altered from 0 to 100. Kernel developers often hard-coded some values to trigger the boost action. But /top-app/ should not be boosted forever. For example, if you're watching a video or listening some music, boost is not preferred for such sustainable tasks. To solve this issue, Joshuous introduced a mechanism call "Dynamic SchedTune Boost", see Ref. It dynamically set the boost for each cgroup task using slot-based tracking system. It is perfect in itself. But if we go through all boost techniques in the kernel, a giant of coupling system will appear and disturb our mind.
Let me try to sort it out.
In the original kernel released by XiaoMi, there are already a few boosting methods implemented by QCOM. Boosting inerface is created and coorperated with performance daemon in userspace. The first one is /proc/sys/kernel/sched_boost. The value is received from a daemon and afterwards triggers a bunch of tasks in the kernel. Codes for these tasks are deeply embedded in HMP, which for now seems impossible to coexist with EAS. To save this interface, Josh again wrote a stub function to build a connection between this interface and boost in schedtune, but he didn't count the value of sched_boost, which was defined from 0 to 3. The problem here becomes simple that we shall map [0 3 2 1] to [0..100]. Thus, I made an effort to write down a function as follows:
C:
return data > 0 ? (4 - data) * 33 : 0;
The factor 33 is trivial and can be changed as you wish. I take 5 for conservative boosting. The returned value is then directly written to the interface /schedtune.boost/ for /top-app/. A positive side effect is that the code can naturally switch on/off the boost status.
The second boost is carried out by codes in soc/qcom/msm_performance.c, which set min/max CPU frequencies upon user touch. Do you remember the original idea behind the /interactive/ CPU governor? xD It's a bit annoying to pull-up the min frequencies constantly in background and waste energy. It seems safe to partially disable this boost in the kernel and just reserve the sysfs name.
The last one locates in cpu-boost.c, cooperated with HMP codes to boost CPU based on event notifier. Totally disable this feature.
After reviewing all boost techniques, we know that CPU frequency is no doubt most critical factor of all. I don't know why QCOM implemented so many boosts, even coupled with each other. I know that msm8998 performs very well without them. I build an experimental EAS kernel, driven by a combination of /schedutil/ and /schedtune/. Tested few days in a small community, it is running good with respect to power efficiency.
Kernel Source
Sorry, no prebuilt kernel here, just sharing the idea about EAS and boost.
After reading more resources, I gathered new information on this topic. The schedtune.boost value of "top-app" was controlled by /libperfmgr/ daemon in userspace, which has been used on Google Pixel phones for years. Therefore, optimization in kernel side seems not that neccessary with libperfmgr.
@strongstCommunity Admin may consider deleting this thread. Thank you.
THREAD LOCKED
Requested by OP.
Regards,
shadowstep
Forum Moderator