Well sadly i don't have an answer for that question yet...
I'm trying to think of a way to put KSM to the test on my android device.
As far as i understand it is possible that the kernel actually causes high CPU usage trying to map and unmap memory pages over and over again.
This issue is known for linux and other virtual machines so it is possible that the Same effect will be on the android vm
Testings that i found are not relevant to android.
For example:
The result is a dramatic decrease in memory usage in virtualization environments. In a virtualization server, Red Hat found that thanks to KSM, KVM can run as many as 52 Windows XP VMs with 1 GB of RAM each on a server with just 16 GB of RAM. Because KSM works transparently to userspace apps, it can be adopted very easily, and provides huge memory savings for free to current production systems. It was originally developed for use with KVM, but it can be also used with any other virtualization system - or even in non virtualization workloads, for example applications that for some reason have several processes using lots of memory that could be shared.
Click to expand...
Click to collapse
http://kernelnewbies.org/Linux_2_6_32
What i would really want to know is what would happen if each of these VMs Would run a different application/game/audio/graphics software at the same time ? or what if the same vm will run many different apps ? and also to compare cpu usage with and without KSM
Guess i'll need a tool for that. something like 'iostat' but for memory diagnostic and another tool to see a per process CPU usage but 'top' is not good enough for that.
Any way, the best test should present clear results with precised data.
I'll keep looking for legit way to put it to the test.
If you can think of a way to test KSM with android, please let me know.
This is a technique that relates mostly to processes like virtualisation. For example, when you load 5 windows XP VMs, you'll have a good 10 - 20 services that are practically the same in memory in each VM. Instead of each service using 10mb (ie, 10mb x 5 = 50mb), you only need say 15 or 20mb using KSM. If you use different applications, it is very unlikely that anything would be saved FOR THAT APPLICATION. However, the main elements of a Windows XP System would still be there (drivers, explorer, firewall, logon, search and so on). Means little in one setup, but when you have several VMs it is shown to be a huge advantage. As we know a simple XP install can use 500mb of RAM actively, and this is fairly uniform across instals.
With android, i don't know if there are specific RAM savings to be had. Don't know enough about the inner workings and the sandbox android puts its apps in or how apps interact with system services. Sadly, i can't think of a good way to test it out either, but i'll be keeping an eye on this topic for someone (much) more knowledgeable to come along.
Harbb said:
Sadly, i can't think of a good way to test it out either, but i'll be keeping an eye on this topic for someone (much) more knowledgeable to come along.
Click to expand...
Click to collapse
Enter bedalus, stands there with a vacant expression on his face. Harbb looks disappointed.
kernels ; battery ; ROM ; gov/sched
That entire paragraph was dedicated to you bedalus, we both know that.
Lol
I hope someone can answer this though.
kernels ; battery ; ROM ; gov/sched
Wait for someone............
Sent from my Nexus S using xda premium
KSM does not improve performance on Android just like that - all enabling KSM does, is enable SUPPORT for the Feature but Applications would have to make use of the feature, which they don't.
You can easily verify this like that :
echo 1 > /sys/kernel/mm/ksm/run
<wait and/or run the Applications of your choice>
cat /sys/kernel/mm/ksm/pages_sharing
IF the above shows a value > 0 then you are making use of KSM else it's just available, without anyone using the feature.
Here's an interesting Article that gives a little more insight :
http://www.linux-kvm.com/content/using-ksm-kernel-samepage-merging-kvm
By the way, the same is true for ZCACHE. If you really want to make better use of your Memory (RAM) then using ZRAM as a Swapdevice does work (and may often make sense, too).
That all said : There appear to be efforts to make use of KSM http://forum.xda-developers.com/showthread.php?t=1464758 - so things may well change ...
any update on this...?
System.out.println("Hello peoples");
==>The purpose of this guide is to help people who don't know anything about programming,aren't modders,guys with knowledge about technology.
==>Initially I loved computers and their capabilities and have a little knowledge on the C and Java languages and just how computers (think).
You have to understand that computing tries to emulate human behaviors on how to solve problems.This is where programming kicks in.
So what is Android?
===================
1)Android in general is an operating system that was meant to run on mobile devices e.g. cell phones
and has expanded to tablets and notebooks.Android is divided into three language groups:
a)the system's framework and apps are written in java.
b)the Android's core [kernel] is pure C -language.
c)the Android's libraries are written in C++.
App libraries are called by apps that need more functionality that java can't provide.These are usually plugins like
decoders e.g. ffmpeg libraries that are used in video decoding,flash-players e.t.c. Here,java native methods are used and the android NDK platform
is used to enable the java apps call these libraries during execution.(Please read further on Android SDK,NDK and Jni).
So what happens when you have just flashed that new Rom.
====================================================================
First you have to understand that cell phones have their own embedded firmware not including the recovery and you will see why.
a)the recovery partition can be flashed to install aftermarket recovery roms.So even if you mess your recovery,you can still install again.(This varies with different phones).
b)their is that system chip which you cannot touch and there is a reason for it.Think of this partition like a PC BIOS.If you mess with your bios
your system is toast aka Bricking the system.Since phones are classed as embedded systems,manufactures don't want people messing with it as it would result into
cryptic errors and system vulnerability.
when the on button is pressed something simple yet complicated happens:
1==>The kernel which is compressed to save space usually in a (zImage) format is deflated or expanded.Since your NAND chips are partitioned,the kernel is given a very
special chunk in which is protected from user data.
2==>The kernel finds which base address it needs to start executing e.g.(0x00200000) and mostly when you put a wrong kernel base
address your phone enters into a boot-loop because arguments are being passed to invalid locations.It is important to know where your kernel base address
starts.You can try looking it up in your kernel sources(try searching for the mach msm folder and into the makefile) or just goggle it up or use Xda-Kitchen.
3==>with the correct kernel base address,execution starts.Usually the (init.rc) file in the (ramdisk folder) gives symlinks and creates structures i.e. folders that will house
modules and sets the correct paths to android files and framework.
4==>After arguments have successfully been passed,the handles are now passed to Android.Basically Android checks for (init.d) scripts that are available
this is true to GingerBread and Cyanogenmod 7.After that audio checks are done followed by camera services and then arguments are passed to (core.jar),a
critical framework file which is huge around 50Mb in size in CyanogenMod 7.
5==>Here the DalvikVM (Dalvik virtual machine) is called and the process of optimizing your system files starts.The framework get optimized first as this contains critical
code needed to run your device.Then your flingers and renderers and called.This are engines used by android e.g. (pixelflnger) which is used in touchscreen.
Your system's sensors are usually started around this point (your compass,light sensors e.t.c)your phone apps e.g. contacts,calendar get optimized around this point
and depending on the number of apps your manufacturer installed,it will take some time.
6==>your network get's activated around this point and is probably the time the capacitive buttons and lights on your gadget light up.This is usually a good indication
that your system has loaded.When your bootanimation ends the handles are passed to activate your home launcher.There is usually still a lot of activity going
on to fully ready your system and this is why if you try to use it immediately especially on low-end phones,your system lags or get (not responding) errors.
common misconceptions
=====================
1==>There is are reason why goggle gave minimum specifications needed to run Android because this is a full operating system(OS) unlike the past relic
phones that ran on 50MHz processors.
2==>please don't complain that some of your Ram is not the same as specified on the phones catalog(e.g. you have 256Mb of Ram but in the task manager it indicates you have 179Mb).
There is a reason to it.There are core processes that eat a chunk of your Ram and are hidden so that you don't try silly stuff like trying to kill them in thinking that your are trying to get more memory.
Think of it like this,it's like trying to kill (services.exe or svchost.exe) processes in Windows.You will just be trying to get system hangs,bluescreens
or just a system crash.
Will Add more info later.Please feel free to correct anything i might have not addressed properly or share your views.
Happy modding.
Kernel topic
============
In simple terms,the kernel is the core of any operating system e.g. windows, Mac,or any Linux distro like Ubuntu and Android.Android kernels come mostly
in the form of a compressed kernel (zImage).The kernel is written in pure C-language,which gives it direct access to memory and registers unlike java
which has to pass through the java VM(virtual machine).This makes code written in C-language to be very fast and robust but also dangerous.
==>Many Androids in the eclair regime ran on kernel 2.6.29. This was not a complete kernel and as by my experience there was alot of code missing from it.
2.6.29
======
==>a lot of androids did not have adb functionality due to the framework being embedded to allow USB mounting to PC.This was a very rigid method
of doing it(also a very old method).
==>In the case of other devices, when viewing the internal task manager,many processes were viewed as (0.00) byte files.In essence you could not determine
the amount of RAM your app was taking.This is true in the case of huawei u8120.
==>In the case of shutting down the phone,even in some cases under load,it did so very fast.It killed threads and handles mercilessly. Many people misunderstood
this concept and thought their phones ran faster as compared to 2.6.32 kernel.
2.6.32.9
========
Here there was a ton of improvements as developers and modders became more aware of support and tweaks.
==>Fixed issues like the internal task managers.It was now possible to accurately know how much RAM your apps were taking.
==>Resolved how the android system shutdown.Instead of merciless killing of handles and threads still running,it killed them appropriately.This is why
when shutting down your system takes a while.You can use adb to see these events.
==>Usb mounting to pc was also made somewhat generic and flexible across many devices.
==>It did change some methods on how the camera is being accessed mostly in eclair,donout and earlier versions of android phones.This issue made
cameras not function.
==>wifi methods were also changed and developers and modders had to re-write their code to allow compatibility.
==>This was also the year of many froyo phones and overclocking was a common thing.
extra notes
===========
During eclair era,many developers were in such a hurry to produce new android phones every few months that they never even thought of long-term support
to newer versions of android that would come much later.This is where i have to praise Iphones for standardisation of its OS across all of its devices.
==>If you try to copy paste code from 2.6.32.9 and paste it into 2.6.29 and expect it to work then expect tons of errors when compiling.The (g_android)
module was properly coded into 2.6.32.9 so if you try enabling it an older kernel,expect errors.
==>If you are a modder and looking to buy a new phone,please see if it has a fan base of coders or support.Avoid buying phones where you will not get
any support from the manufacturers or other devs e.g Huawei Technologies.This company sucks alot.After they produce a phone they forget about you the customer
so you will have to handle the upgrades all by yourself.
Do not use this command (make -i)when compiling kernels.It will skip errors and you may smile after it's finished but the end is just a tragedy.your kernel is bound
not to function properly or even function at all.
Happy modding.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Wandering through the forums and various websites dedicated to Android, we are constantly confronted with tips on how to increase the performance of the smartphone. Some recommend to include swap, others - add special value to build.prop, and others - to change variables of the Linux kernel. Such recipes in different ways you can find a huge amount of that on the XDA and 4PDA. But do they actually work
Tenacity with which some seemingly competent smartphone users are trying to push their ideas public optimum adjustment Android and the underlying Linux kernel. And the right to it was limited to a slight tuning virtual memory management subsystem, or the inclusion of experimental options. No, we usually offer a very long use scripts that change literally every variable core, remount filesystems with different odd options, including the swap, activate various system daemons and perform billions of different operations.
No, well, you can, of course, assume that the Linux kernel, Android and proprietary firmware for smartphones develop illiterate idiots, whose work must be radically alter, but in practice some reason it turns out that the most famous tuning tools, published on XDA, - it nothing but a hodgepodge of disparate huge number of recommendations, it is not clear who invented and no one knows why. The absurdity of the situation reaches that these instruments can be found rows copied unchanged from the scripts to increase Linux-server performance under heavy loads (I'm not kidding, look at the contents of the famous script ThunderBolt!).
In general, the situation is more complicated than. All advise all, no one suggests anything, and those who understand something, sitting and drinking tea and laughing over what's happening.
Swap
Let's start with the swap - the most absurd ideas of all that you can think of for use in smartphones. Its purpose is to create and connect the paging file, thereby manage to free storage space in memory. The idea itself is certainly sensible, but only if it is a server, which rests on the interactivity of nowhere. Using your phone regularly used pagefile will lead to lags arising from slips past the cache - just imagine what will happen if an application tries to display one of their icons, and it will be in the swap, which will have to re-load the disc, after freeing up space by placing data swap another application. Horror.
Some users can be argued that in fact after the swap no problems, but for this we must thank the mechanism lowmemorykiller, which regularly kills very swollen and have not used the application. Thanks to him, the device with 1GB of memory can never reach the necessary performance data in a swap. He is the reason why, in contrast to the Linux-desktop on the Android swap is not needed.
Verdict: A very stupid idea, the implementation of which is fraught with serious lags.
zRAM
The idea is so right that even Google recommends zRAM for KitKat-based devices in the event that the amount of RAM is less than 512 MB. Only snag is that the method only works for modern cost devices based on multi-core processors from the budget any MTK and 512 MB of RAM. In this case, the encryption stream can be taken to separate the kernel and do not care about performance.
On older devices with a single core, and which recommend the use of this technology, we again get the lags, and in fairly large quantities. The same, incidentally, applies to technology KSM (Kernel Same Page Merging), which allows you to combine identical memory pages, thus freeing space. It also recommended that Google, but on older devaysakh leads to an even greater lags, which makes sense, given the constantly active core thread that runs continuously from memory in search of duplicate pages.
Verdict: it depends on the device, in most cases, the system slows down.
Seeder
At the time this application has done a lot of noise and gave rise to many analogues. The network has a huge number of reports of alleged phenomenal growth performance of the smartphone after installation. Homegrown custom firmware collectors have begun to include him in their assembly, and the author was declared a savior. And all this despite the fact that Seeder not doing anything dirty hacks, but just corrected a stupid bug Android.
The bug consisted in the fact that some high-level components of the Android runtime actively used the file /dev/random to get entropy. In some moments buffer /dev/random devastated, and the system is blocked until it is filling the required amount of data. And as he filled that have been reported from various sensors, buttons and sensors of the smartphone, the time for this procedure took so much time to notice that lag.
To solve this problem the author Seeder took Linux-demon rngd, compiled it for Android inastroil so that he took random data from a much faster (but also much more predictable) /dev/urandom, and every second merges them into /dev/random, without allowing the latter exhausted. As a result - the system never experienced a lack of entropy and work quietly.
This bug was closed back in Google Android 3.0, and it would seem, we do not need to think about Seeder. But the fact that the application has since actively developed and even today, is recommended by many "experts" for the application. Moreover, the application has several analogues (eg, sEFix), and many of the creators of the scripts/tools to accelerate still include this functionality in their creations. Sometimes it is the same rngd, sometimes - the demon haveged, sometimes just symlink /dev/urandom on /dev/random.
Everyone who tried it, excitedly shouting about the effectiveness of the solution, however, according to Ricardo Cerqueira from the company Cyanogen, in newer versions of Android /dev/random is used in all three components: libcrypto (encryption SSL-connections, generating SSH keys and etc.), wpa_supplicant/hostapd (to generate the WEP/WPA-keys) and several libraries for generating random ID to create ext2/3/4 filesystems.
Application Efficiency in today's Android, in his opinion, is not connected with the completion of the pool /dev/random, and that rngd constantly awakens the device and causes it to increase the frequency of the processor, which has a positive effect on performance and negative on the battery.
Verdict: The placebo effect.
Odex
Stock firmware smartphones always odex. This means that along with the standard package for Android apps in APK format directory /system/app/ and /system/priv-app/ (since KitKat) are also of the same name files with the extension odex. They contain so-called optimized bytecode applications already passed through the validator and optimizer virtual machine and recorded in a separate file (this is done using dexopt utility).
Meaning odex files to offload virtual machine and thus speed up the launch of the application (runoff). On the other hand, ODEX files to prevent modifications to make to the firmware, create problems with the update, and for this reason many custom ROMs (including CyanogenMod) distributed without them. Return (or rather, generate) files odex a variety of ways, including using simple tools/scripts like Odexer Tool. Using them is easy, and many of the "experts" are advised to do so.
The only problem is that this is purely a placebo. Not finding odex-files in the directory/system, the system itself will create them the next loaded and placed in the directory /system/dalvik-cache/. This is what she does when loading a new firmware on the screen the message "Busy ... Optimizing Applications." In relation to applications from the convenience store is also, incidentally, works. But at the stage of installation of the software.
Verdict: The placebo effect.
Lowmemorykiller tweaks
The implementation of multitasking in Android is very different from other mobile operating systems and is based on the classical model. Applications can work quietly in the background, in the system there are no restrictions on the number, the functionality of the transition to a background execution is not curtailed. All as on the desktop, except for one detail: the system has every right to kill any background application in the case of lack of memory, or (since KitKat) excessive greed application resources.
This mechanism, called lowmemorykiller, was coined to, retaining features of a full-fledged multi-tasking OS, Android could live normally in a limited amount of memory and lack of swap-partition. The user can easily launch any application and quickly switch between them, and the system will take care of the long-unused application completion and to always remain free memory in the device.
In the early days of Android purpose of this mechanism for many users it was unclear why have become popular so-called task-killer - apps that from time to time to wake up and have completed all background applications. Profits in this case, it was considered a large amount of free RAM, which was perceived as a plus, though no advantages in this, of course, was not. But there were many disadvantages in the form of a longer switch between applications, increased battery consumption and problems c awakening in the morning the owner (Service also kills).
Over time, multitasking principles of understanding has come, and from task-killers gradually abandoned. However, they were quickly replaced by another trend - tuning of lowmemorykiller mechanism (for example, by MinFreeManager applications). The main idea of the method is to lift the boundaries of filling the RAM at which the system will start to kill background apps. A sort of the way ", and us and you", which allows you to free up some memory by regular means, without disturbing ideas Android multitasking.
But what it ultimately leads? For example, the standard value memory is full of borders - a 4, 8, 12, 24, 32 and 40 Mb, that is when the free storage space of 40 MB will be killed by one of the cached applications (loaded in memory, but is not running, is this optimization Android ), with 32 - Content Provider, has no customers, 24 - one of the seldom-used back-end application, then go to the expense of service processes application (for example, the music player service), visible on the app screen and the current running application. The difference between the last two is that the "current" - this application, which is currently dealing the user, and the "visible" - is that, for example, has a notification in the status bar or display on top of the screen any information.
In general, all this means that the smartphone will always be available 40 MB of memory, which is enough to accommodate another application, and then start LKM flow and begin cleanup. All OK, everyone is happy. The system uses the maximum memory. Now imagine what would happen if the user take advantage of advice homebrew "expert", and raise these values so that the latter would be, well, let's say, 100 MB (usually raised only the last three values). In this case, it happens one simple thing: the user will lose 100 - 40 = 60 MB of memory. Instead of using this space to store back-end applications, it is useful, as it reduces the time to switch to them, and the charge of the battery, the system will keep it free is not clear why.
It is fair to say that the LKM tuning can be useful for devices with very very little memory (less than 512) and Android 4.X on board, or to temporarily increase thresholds. Some developers tweaks directly recommend the use of "aggressive" setting only if you run heavy software like hi-end games, and all the rest of the time to stay on the standard. This really makes sense.
Verdict: better not to touch.
I/O tweaks
The scripts that are published on the forums, you can often find tweaks I/O subsystem. For example, in the same script ThunderBolt! has the following lines:
Code:
echo 0 > $i/queue/rotational;
echo 1024 > $i/queue/nr_requests;
The first gives the I/O scheduler to understand that he is dealing with a solid state drive, the second increases the maximum size of the queue IO 128 to 1024 ($i variable in commands contains a path to the tree of block device in /sys, eg /sys/block/mmcblk0/, the script runs on them in the loop). Hereinafter you can find the following line relating to the CFQ scheduler:
Code:
echo 1 > $i/queue/iosched/back_seek_penalty;
echo 1 > $i/queue/iosched/low_latency;
echo 1 > $i/queue/iosched/slice_idle;
This is followed by a few more lines belonging to other planners (by the way, pay attention to a whole extra semicolon at the end of instruction). What all of these lines is not so? The first two commands are pointless for two reasons:
1. Schedulers I / O in a modern Linux kernel itself able to understand what type of storage medium they deal.
2. Such a long input-output queue (1024) completely useless on a smartphone. Moreover, it is meaningless, even on the desktop and is used on heavy duty servers (of tuning recommendations which it, apparently, and got into the script).
The last three are meaningless for the simple reason that for a smartphone, where there is virtually no separation applications prioritized in the input-output and there is no mechanical drive, the best planner - is the noop, that is simple the FIFO-queue - who first turned to memory, he also got access. And this scheduler is not any special settings. Therefore, all these multi-screen lists commands better replaced by a simple cycle:
Code:
for i in /sys/block/mmc*; do
echo noop > $i/queue/scheduler
echo 0 > $i/queue/iostats
done
In addition to enabling noop scheduler for all drives it off the accumulation of statistics I/O, which should also have a positive impact on the performance (although this is only a drop in the sea, which will be completely invisible).
Another tweak that can often be found in the scripts tuning performance - this increase readahead values for memory cards up to 2 MB. readahead mechanism for early reading data from the media even before the application requests access to these data. If the kernel sees that someone long enough to read the data from the media, it is trying to figure out what data will be needed in the future application and pre-loads them into RAM, thereby enabling to reduce the time of their return.
It sounds cool, but, as practice shows, readahead algorithm is very often wrong, which leads to unnecessary operations of input-output and consumption of RAM. High values readahead (1-8 MB) are recommended for use in RAID-arrays, whereas on the desktop or smartphone is better to leave everything as is, that is 128 KB.
Verdict: in addition to noop, do not need anything.
Tweaks virtual memory management system
In addition to the subsystem I/O, it is also common to do tuning virtual memory management subsystem. Often, change affects only two kernel variables: vm.dirty_background_ratio and vm.dirty_ratio, which allow you to adjust the size of the buffer for storing the so-called dirty data, ie the data that has been written to disk application, but more are still in memory and waiting until they are written to disk.
Typical values of these variables in the desktop Linux-distributions and Android are as follows:
Code:
* vm.dirty_background_ratio = 10
* vm.dirty_ratio = 20
This means that when the "dirty" data buffer size in 10% of the total amount of RAM wake pdflush nuclear flow and starts to write data to disk. If the operation of recording data on the disk will be too intense and even though the job pdflush, the buffer will continue to grow, then when it reaches 20% of the amount of RAM the system switches all the subsequent write operation in synchronous mode (without pre-buffer) and the work of writing to disk application will be blocked until such time as the data is written to disk (in the terminology of Android is called a lag).
It is important to understand that even if the buffer size is not reached 10%, the system anyway pdflush starts the flow after 30 seconds. What we are given this knowledge? In fact, anything that we could use for their own purposes. The combination of 10/20% is quite reasonable, for example, on your smartphone with 1 GB of RAM is about 100/200 MB of memory, which is more than enough in terms of rare bursts records that speed is often below the speed record in system NAND-memory, or SD-card (when installing software or copying files from a computer). But the creators of scripts optimization with this, of course, disagree.
For example, in Xplix script can find something like this (in the original, they are much longer because of the checks on the amount of RAM and use BusyBox):
Code:
sysctl -w vm.dirty_background_ratio=50
sysctl -w vm.dirty_ratio=90
These commands apply to devices with 1 GB of memory, that is, set limits on "dirty" buffer equal to (approximately) 500/900 MB. These high values are absolutely meaningless for the smartphone, as only work under constant intense recording on the disc, that is, besides for heavy server. In a situation with a smartphone they are no better than the standard. By the way, in the script ThunderBolt! used much more reasonable (and close to the standard) values, but I doubt that by their application the user will notice at least some difference:
Code:
if [ "$mem" -lt 524288 ];then
sysctl -w vm.dirty_background_ratio=15;
sysctl -w vm.dirty_ratio=30;
elif [ "$mem" -lt 1049776 ];then
sysctl -w vm.dirty_background_ratio=10;
sysctl -w vm.dirty_ratio=20;
else
sysctl -w vm.dirty_background_ratio=5;
sysctl -w vm.dirty_ratio=10;
fi;
The first two commands are run on smartphones with 512 MB of RAM, the second - with 1 GB, and others - with more than 1 GB. But in fact there is only one reason to change the default settings - a device with a very slow internal memory or memory card. In this case it is reasonable to spread the values of the variables, that is, to make something like this:
Code:
sysctl -w vm.dirty_background_ratio=10
sysctl -w vm.dirty_ratio=60
Then, when a surge system write operations, without having to record data on the disc, up to the last will not switch to synchronous mode, which will allow applications to reduce lag when recording.
Verdict: better not to touch.
P.S.
There are numerous and smaller optimizations, including the "tuning" of the network stack, changing the variables of the Linux kernel and Android (build.prop), but 90% of them have no effect on the real performance of the device, while the remaining 10% or improve some aspects of behavior devices at the expense of others, or so insignificant increase productivity, you do not even notice it. From what really works, we can note the following:
****Acceleration. The small acceleration to improve performance and andervolting - save a little battery.
****Database Optimization. I seriously doubt that this will give a noticeable increase in speed, but the theory tells us that the work should be.
****Zipalign. Ironically, despite the built-in Android SDK feature content alignment within the APK-file in the store you can find a lot of software is not transmitted through zipalign.
****Disable unnecessary system services, removing unused system and seldom-used third-party applications.
****Custom kernel with optimizations for a specific device (again, not all nuclei are equally good).
****Already described I/O scheduler noop.
****Saturation algorithm TCP westwood +. There is evidence that he is in wireless networks more efficiently used in the default Android Cubic. Available in custom kernels.
Useless settings build.prop
LaraCraft304 from XDA Developers forum has conducted a study and found that an impressive number of /system/build.prop settings that are recommended for use "experts" do not exist in the source AOSP and CyanogenMod. Here's the list:
ro.ril.disable.power.collapse
ro.mot.eri.losalert.delay
ro.config.hw_fast_dormancy
ro.config.hw_power_saving
windowsmgr.max_events_per_sec
persist.cust.tel.eons
ro.max.fling_velocity
ro.min.fling_velocity
ro.kernel.checkjni
dalvik.vm.verify-bytecode
debug.performance.tuning
video.accelerate.hw
ro.media.dec.jpeg.memcap
ro.config.nocheckin
profiler.force_disable_ulog
profiler.force_disable_err_rpt
ersist.sys.shutdown.mode
ro.HOME_APP_ADJ
To be continued...
thanks man!
this helped me understand some things
"No, well, you can, of course, assume that the Linux kernel, Android and proprietary firmware for smartphones develop illiterate idiots, whose work must be radically alter"
this made me lol
This...
Was...
AWESOME!
Pure information furthermore useful bits and pieces. Sorry for the necro but I just felt plain wrong to tap a button to say thanks. I really felt like I'd be the minimum to write thanks personally. Thank you very much for this post.
I swear to you windowsmgr.max_events_per_sec works flawlessly, the higher number, the more content will be able to load on launcher without lag. I used to test it on my J7 pro android 8.0
I subscribe the OP's statements that we are constantly are searching for optimization(s) of our Android device. I used all kind of Android devices, like Sony, Oppo, etc for many years with varying satisfaction, also regarding Android updates. I know that what I'm going to say now, is very sensitive in the Android community, but nevertheless I will post it. After having used Fitbit as my fitness trackers/smartwatches, I noticed the release of the Apple iWatch 6 and I was stunned about the capabilities of this watch versus all other smarwatches. Alas I needed also an iPhone to get it up and running. Let me be clear, I never was an Apple fan due to it's too strict policy and the fact that you were not able to make your own homescreen. But, since the release of iOS 14 this all changed, so I decided to get over my Apple resistance and bought the Apple 12 Pro Max. Using this now for a few months, this is the best upgrade I ever made. Everything runs smooth, fast, lot's of space, smooth connection with the iWatch, etc etc. I designed my own home display even on an Apple device (see attachment). Looks exactly the same as the home display I had on all of my former Android devices. Hope this information is in some way helpfull for you all. Kindest regards kuzibri
P.S. If you've got interested in more information about the Apple 12, see my threads in the Apple fora of XDA:
1. https://forum.xda-developers.com/t/q-a-template-for-the-apple-iphone-12-pro-max.4322579/
2. https://forum.xda-developers.com/t/ask-away-thread-for-all-apple-iphones.4323471/