Hello everyone, after a long day of research(googling) and tweaking with various things with this phone I think I may have stumbled upon a way to run our 5Xs in 32-bit mode. In the system folder lies a file called build.prop(Make a copy of this and place it somewhere safe), pull this file and edit these lines:
dalvik.vm.isa.arm64.features=default
dalvik.vm.isa.arm.features=default
and change them to:
dalvik.vm.isa.arm64.features=lpae,div
dalvik.vm.isa.arm.features=lpae,div
after you're done editing push the build.prop file back to the system folder and apply these settings: Chmod 0644 (rw-r-r)
I personally have done this tweak and noticed that even when running heavy apps such as Chrome with multiple tabs open and YouTube while playing 1080p videos in split screen mode that the system always has 400 - 600mb of ram available for use. I would love for a developer to please pipe in and explain what exactly these edits are doing. From my understanding these edits are telling the processor to execute code in 32-bit(exclusively?) instead of the default 64-bit and 32-bit mode. If anyone else is open to try this please give your experiences with this tweak.
Interesting, gonna try this... I guess there's not even a point in having a 64 bit processor with only 2GB of RAM
edit: It definitely feels kinda different... I managed to get Facebook, Messenger, Snapchat, Instagram, Google Photos, YuBrowser and YouTube opened at same time with 281MB to spare.
If anyone is interested to no about Linux.arm lpae here's some information that might be interesting...
Also this is very interesting..
64-bit operation enables applications to use a larger virtual address space. While the Large
Physical Address Extension (LPAE) extends the physical address space of a 32-bit
processor to 40-bit, it does not extend the virtual address space. This means that even with
LPAE, a single application is limited to a 32-bit (4GB) address space. This is because
some of this address space is reserved for the operating system.
• Software running on a 32-bit architecture might need to map some data in or out of
memory while executing. Having a larger address space, with 64-bit pointers, avoids this
problem. However, using 64-bit pointers does incur some cost. The same piece of code
typically uses more memory when running with 64-pointers than with 32-bit pointers.
Each pointer is stored in memory and requires eight bytes instead of four. This might
sound trivial, but can add up to a significant penalty. Furthermore, the increased usage of
memory space associated with a move to 64-bits can cause a drop in the number of
accesses that hit in the cache. This in turn can reduce performance.
The larger virtual address space also enables memory-mapping larger files. This is the
mapping of the file contents into the memory map of a thread. This can occur even though
the physical RAM might not be large enough to contain the whole file.
Does this have any impact on battery? Obviously, just using less memory is good but I'm searching for more battery without sacrificing performances too much.
edoardotavecchio said:
Does this have any impact on battery? Obviously, just using less memory is good but I'm searching for more battery without sacrificing performances too much.
Click to expand...
Click to collapse
To be honest I don't think that it's going to have any significant changes to battery life it's more of a way that the memory management is handled between 32bit &64bit process but I'm no expert..
dog121 said:
To be honest I don't think that it's going to have any significant changes to battery life it's more of a way that the memory management is handled between 32bit &64bit process but I'm no expert..
Click to expand...
Click to collapse
Yes I know but as an information techonology student and Android enthusiast I've found that everything could bring unexpected results lol so I'm Just asking to the OP for some testing
what about stability? apps like play services are made for 64bit devices, doesn't this mod cause stability problems?
edoardotavecchio said:
Yes I know but as an information techonology student and Android enthusiast I've found that everything could bring unexpected results lol so I'm Just asking to the OP for some testing
what about stability? apps like play services are made for 64bit devices, doesn't this mod cause stability problems?
Click to expand...
Click to collapse
Can't answer that .. Can say that it seems to be running with out any issue but I can't even say whether or not these two lines of code are actually taking affect ..After reading a considerable amount of information on lpae I seriously don't think that this is achieving any significant changes to the system management which Is kernel related as far I I know ..But like I said I'm no expert and could be totally wrong
I'm actually really curious as to what effects this could have, and if one could go further toward 32-bit based RAM management. I'm not currently rooted, so I can't modify my build.prop, but I certainly plan to try it soon. As the OP said, I'm wondering if a developer, or perhaps just someone more knowledgable could provide any input as to what this is really doing. Always exciting to find something new!
Should we wait and hope that someone sees this post or maybe PM some of the developers for this device asking for an opinion?
Appreciate the responses guys, I'm hoping that this thread will garner enough attention to get a developer in here and help us out a bit with this.
HesThatGuy said:
Hello everyone, after a long day of research(googling) and tweaking with various things with this phone I think I may have stumbled upon a way to run our 5Xs in 32-bit mode. In the system folder lies a file called build.prop(Make a copy of this and place it somewhere safe), pull this file and edit these lines:
dalvik.vm.isa.arm64.features=default
dalvik.vm.isa.arm.features=default
and change them to:
dalvik.vm.isa.arm64.features=lpae,div
dalvik.vm.isa.arm.features=lpae,div
after you're done editing push the build.prop file back to the system folder and apply these settings: Chmod 0644 (rw-r-r)
I personally have done this tweak and noticed that even when running heavy apps such as Chrome with multiple tabs open and YouTube while playing 1080p videos in split screen mode that the system always has 400 - 600mb of ram available for use. I would love for a developer to please pipe in and explain what exactly these edits are doing. From my understanding these edits are telling the processor to execute code in 32-bit(exclusively?) instead of the default 64-bit and 32-bit mode. If anyone else is open to try this please give your experiences with this tweak.
Click to expand...
Click to collapse
That will not make them run in "32-bit mode" what you can do when compiling is making certain memory calls 16 bit wide and that can actually increase performance in some cases.
I'd done that at compile time for some ROM's and kernels and it does work fairly well while not affecting performance or stability negatively.
LPAE is just a way for 32 bit OS's to acces memory above the 4GB limit, i don't know why you think that would do anything at all. It will literally do NOTHING for a 64 bit kernel based OS and it will have the opposite effect on a 32 bit Kernel OS that has support for LPAE.
Here's a writeup on LPAE http://elinux.org/images/6/6a/Elce11_marinas.pdf
It's a kernel enabled feature in 32 bit systems, if it's enabled it can be disabled in the build.prop but it cannot be enabled since it's enabled by default in 32 bit kernels.
The only thing a 32 bit mode would do is slow down memory access for a 64 bit kernel, it's silly and unimportant since 32 bit code will be run exactly the same except access to anything above the 4GB limit in memory.
---------- Post added at 06:54 AM ---------- Previous post was at 06:51 AM ----------
edoardotavecchio said:
Does this have any impact on battery? Obviously, just using less memory is good but I'm searching for more battery without sacrificing performances too much.
Click to expand...
Click to collapse
Since it is only applicable to 32 bit kernels it won't do anything and won't have any effect on anything what so ever. You can add a line that reads "make.my.phone.fastest=yes" and it will have the exact same effect.
@Nicktheprofessor My post is not directed specifically towards LPAE, it is focused on finding out what exactly these edits are telling the processor to do. The main command if anything is "div" which from my understanding is telling the processor to execute code with 32-bit instructions exclusively instead of the default of executing in 64-bit and falling back to 32-bit when necessary. Thank you for adding to the conversation though.
HesThatGuy said:
@Nicktheprofessor My post is not directed specifically towards LPAE, it is focused on finding out what exactly these edits are telling the processor to do. The main command if anything is "div" which from my understanding is telling the processor to execute code with 32-bit instructions exclusively instead of the default of executing in 64-bit and falling back to 32-bit when necessary. Thank you for adding to the conversation though.
Click to expand...
Click to collapse
OK, let's make sure this is very clear then.
The DIV bit cannot turn 64 bit compiled instructions into 32 bit instructions, it doesn't work that way, the DIV bit is a 64 bit specific instruction set.
Now if you have a 32 bit system with LPAE support you can set DIV to LPAE so that memory addressing can be made using 64 bit memory allocation.
If you have a 64 bit system running a 64 bit instruction set it's on no matter what you do, you need to use a 32 bit instruction set in the code itself to change that.
Here's a very simple explanation: https://www.tptp.cc/mirrors/siyobik.info/instruction/DIV.html
It shouldn't be too hard to rewrite the specific kernel additions and compile it in a 32 bit instruction set but you'd have to provide the LPAE layer to get it to communicate with the 64 bit layer.
What you'd end up with would be horridly slow though and i don't see the point in your endavour, do you even understand the concept of instruction sets?
@Nicktheprofessor Correct me if I'm wrong please. My basic understanding of instruction sets are that they tell the processor how to operate in general and how to execute code to run different software.
As for my endeavor, I'm looking into a way of reducing the system's memory usage as I don't feel that 2GB of RAM for a 64-bit Android system is truly enough. Thanks again though for providing info for me to learn about this stuff.
HesThatGuy said:
@Nicktheprofessor Correct me if I'm wrong please. My basic understanding of instruction sets are that they tell the processor how to operate in general and how to execute code to run different software.
As for my endeavor, I'm looking into a way of reducing the system's memory usage as I don't feel that 2GB of RAM for a 64-bit Android system is truly enough. Thanks again though for providing info for me to learn about this stuff.
Click to expand...
Click to collapse
The point is that you can't run 64 bit native code as a 32 bit instruction set, it is 64 bit as is in source and in it's binary form, it cannot be executed using a 32 bit instruction set. To test this for yourself, try to run 64 bit code on a 32 bit system, it won't work and neither could you run the phone as a 32 bit system executing 64 bit code.
To actually reduce a memory footprint you'll need compilation flags, i suggest using a 16-bit addressing alternative (-mfpu=neon-fp16 -mfp16-format=alternative) instead.
I used to use that on another phone and it did actually help a bit.
2GB is plenty for 64bit though, especially since we're using ZRAM and 64 bit allocations will have higher compression values.
Nicktheprofessor said:
The point is that you can't run 64 bit native code as a 32 bit instruction set, it is 64 bit as is in source and in it's binary form, it cannot be executed using a 32 bit instruction set. To test this for yourself, try to run 64 bit code on a 32 bit system, it won't work and neither could you run the phone as a 32 bit system executing 64 bit code.
To actually reduce a memory footprint you'll need compilation flags, i suggest using a 16-bit addressing alternative (-mfpu=neon-fp16 -mfp16-format=alternative) instead.
I used to use that on another phone and it did actually help a bit.
2GB is plenty for 64bit though, especially since we're using ZRAM and 64 bit allocations will have higher compression values.
Click to expand...
Click to collapse
Ahh I see now, I'm still learning all there is to know about how the Android ecosystem works and I appreciate the responses and info my dude. Addressing your ZRAM statement, I would like to find a way to run this phone without ZRAM and without sacrificing memory space as I notice frequently how slow it is for the phone to push & pull things in & out of swap especially when the swap space is nearly filled.
Nicktheprofessor said:
The point is that you can't run 64 bit native code as a 32 bit instruction set, it is 64 bit as is in source and in it's binary form, it cannot be executed using a 32 bit instruction set. To test this for yourself, try to run 64 bit code on a 32 bit system, it won't work and neither could you run the phone as a 32 bit system executing 64 bit code.
To actually reduce a memory footprint you'll need compilation flags, i suggest using a 16-bit addressing alternative (-mfpu=neon-fp16 -mfp16-format=alternative) instead.
I used to use that on another phone and it did actually help a bit.
2GB is plenty for 64bit though, especially since we're using ZRAM and 64 bit allocations will have higher compression values.
Click to expand...
Click to collapse
I dont understand, if you are using 16bit adress and 64bit words u dont get 2 GB ram..
2^16*64b/8b = 524,288 B of ram...
By the same calculation 28 bits would be enough for 2GB of ram with 64bit words.
If u lower the word size u need more adress space to adress the same memory, so i dont understand why 16bits?
Sent from my Nexus 5X using Tapatalk
InterrtuptoR said:
I dont understand, if you are using 16bit adress and 64bit words u dont get 2 GB ram..
2^16*64b/8b = 524,288 B of ram...
By the same calculation 28 bits would be enough for 2GB of ram with 64bit words.
If u lower the word size u need more adress space to adress the same memory, so i dont understand why 16bits?
Sent from my Nexus 5X using Tapatalk
Click to expand...
Click to collapse
It's known as half-precision floating point and it can improve performance in some cases and save cache space but you still have 64 bit code and 64 bit memory allocation.
You can't fix that without actually rewriting code.
---------- Post added at 03:32 AM ---------- Previous post was at 03:27 AM ----------
HesThatGuy said:
Ahh I see now, I'm still learning all there is to know about how the Android ecosystem works and I appreciate the responses and info my dude. Addressing your ZRAM statement, I would like to find a way to run this phone without ZRAM and without sacrificing memory space as I notice frequently how slow it is for the phone to push & pull things in & out of swap especially when the swap space is nearly filled.
Click to expand...
Click to collapse
Well you could just edit the init files and not have ZRAM at all but still support for it in the kernel, the phone will still work just fine but i sincerely doubt you will see much improvement.
Also the cache speeds are not slow in the least, i don't know where you get that from considering that decompression is done on the fly using the fastest algorithm possible and uses all available cpu's. I don't think you can improve on that much.
SWAP space on this phone is ZRAM, there is no physical memory put aside to do that job so...
However, unchanged code will readily be swapped to disk anyway, that is simply the way the Linux kernel works, it will keep the data in memory and just make a note of the disk address for the unchanged program so perhaps that is what you are talking about?
Nicktheprofessor said:
It's known as half-precision floating point and it can improve performance in some cases and save cache space but you still have 64 bit code and 64 bit memory allocation.
You can't fix that without actually rewriting code.
---------- Post added at 03:32 AM ---------- Previous post was at 03:27 AM ----------
Well you could just edit the init files and not have ZRAM at all but still support for it in the kernel, the phone will still work just fine but i sincerely doubt you will see much improvement.
Also the cache speeds are not slow in the least, i don't know where you get that from considering that decompression is done on the fly using the fastest algorithm possible and uses all available cpu's. I don't think you can improve on that much.
SWAP space on this phone is ZRAM, there is no physical memory put aside to do that job so...
However, unchanged code will readily be swapped to disk anyway, that is simply the way the Linux kernel works, it will keep the data in memory and just make a note of the disk address for the unchanged program so perhaps that is what you are talking about?
Click to expand...
Click to collapse
For improvement in speeds you would see a nice gain if you disabled ZRAM as the recent apps you are using will be in RAM instead of swap(flash storage). We both know that flash storage for as fast as it is is still way slower than RAM. You can test this yourself by disabling ZRAM and setting swappiness to 0 and then opening up a few apps and switching between them. It is noticeably faster. Also, ZRAM compression on the 5X is done exclusively on the small cluster by default (source: https://android.googlesource.com/device/lge/bullhead/+/master/init.bullhead.rc#69)
I understand that swap space is from ZRAM. I also made a mistake with the second part of that statement as I was thinking at the time that ZRAM compresses RAM to use for swap space when it actually compresses some of the flash storage to use for swap space.
ZRAM doesn't use flash.
https://en.wikipedia.org/wiki/Zram
Related
Since Sony Xperia X10 is now running on 2.1, topics related to 1.6 is not mentioned here.
This thread are created based on compilation of other threads related to optimization, and meant as an entry point for user interested in optimization.
Understanding your Android
Just to put something short, so we can understand our Android and some points related to optimization better.
Android is an open source operating system owned by Google that is maintained by Android Open Source Project (AOSP). The operating system is based on modified Linux kernel, where most of the application is written in Java language and running on DalvikJVM.
Android do things differently than old generation OS like Symbian, and below is the explanation related to performance.
Unlike Symbian, Android designed to have as many as application loaded and running in the OS, it maintain list of least used application that will be unloaded when a requests for more memory is made when the free OS memory is already low.
These are the nature of JVM, where allocation and deallocation of memory is managed by garbage collector as doing things in bulk is faster then working with small chunks. So you don't have to be alarmed when you open a memory viewer application and see your Android is running on low memory. Freeing RAM with task killer is only momentarily, as you uses the phone again, the free memory will goes down again.
Android phones stores system application, data and files internally in NAND flash area and stores user data in internal memory storage or external storage such as SD cards. This memory is different than your operating sytem memory.
Operating system memory is memory allocated for the kernel, native application and most application you download from market. Installing a lot of application will not directly reduce free RAM, nor uninstalling or removing files will increase free RAM directly. Action such as removing ringtones, wallpaper and even Sony PC Companion ISO will not free your RAM
In general there are two type of android application. One is a standalone application that only run if you open the application, and the other one is running even you haven't open the application which called service.
By design, guideline and suggested practice, application should not continue to run lengthy processing when it get pushed to background via home button, back button or switching to other application; properly build application will just go idle. Which means you should be less paranoid about application eating you processing power.
But service is meant to run lengthy operation as they don't have user interface and runs in background. Some service meanth for pushing or pulling data from internet, reading your files and do processing like playing songs, or just doing something then update the widget just to make you happy. Unnecessary services are the things that you should be aiming if you want to optimize your Android.
General FAQ about Optimizing Sony Xperia X10 2.1
I just updated to 2.1 and my phone really feel slower than 1.6
Since you had been using 1.6 for quite some time, your SD card should have quite a lot of photo and media. Just after you updated to 2.1, and add your Google and maybe Facebook account, the new Face Recognition service is actually already starting to scans all your photo, then when your Google and Facebook contact arrived, it will try it best to match photo and contact. This new Face Recognition really kicks hard in your processor, then after a while your phone will be as fast and even better than old stock 1.6.
I still feel that the phone is slow, is there any simple and quick way to optimize
The simple and quick to optimize your phone instantly is by changing the 2.1 dalvikvm to JIT capable dalvikjvm. You can read and apply them by reading the thread referred below, but before you do that open the below link in background tab and please do read more first.
Android 2.1 OPTIMISER V002 by Jerpelea
2.1 Customizer v0.99.1 by ttxdragon
Both optimizer contains script that will erase your "junk/unused" application from your phone, be sure to read them first before executing. My suggestion is you apply JIT modification first, before going optimizing by remove your "junk/unused" application.
Please do remember that you have to Root your X10 first.
How to root the phone
You can root the phone using methods below.
OneClick z4root Android Application
SuperOneClick Windows Application
Is [INSERT APP NAME] here is save to remove?
By removing unused application, you will gain certain amount of performance gain. Below are the links with app list.
2.1 Customizer v0.99.1 by ttxdragon
Official List of Apps that Can be Removed from a 2.1 x10 by exekias
And still a lot more in other Sony Ericsson X10 forum section but those two is quite complete
And in case you forgot to make backup you can go to
2.1 System Apps - In Case You've Deleted Them by XperiaX10iUser
After doing all that my Quadrant Benchmark is still low
You should run Quadrant as least two or three time or until you get best score, the first one usually yield low score, because a lot of memory allocation process to Quadrant happening during the first run.
Tuning Utilities
Memory Usage - Application to see how much memory used by your application and services
Advanced Task Manager - Application to see is your application running on foreground, background or idle and its memory usage
Quadrant Standard - General benchmarking tools to see if your changes make improvement
Linpack - Processor benchmarking
Titanium Backup Pro - Back up application, the paid version can freeze your app rather then uninstalling it.
Fine Tuning Guide
About Widget, Application shortcut and Live Wallpaper
Even though widgets looks really good in your phone, some widgets required simple periodic process for updating its display, some have a full blown service running to support it. A very instant example that you can see in your phone is the Power Control widget and the new Status Switch widget.
Power Control widget update triggered by configuration change such as wifi on and off, while Status Switch widget which have a battery level is triggered by a running service. Just put Status Switch widget then go to Settings -> Application -> Running Services. Then you will see there a Status Switch Update service running in background to update the battery level.
By selectively put widgets on your home screen, you can gain extra processing and memory. Timescape widget is even worse, it have three service running to support it.
Application shortcuts also uses extra memory in your home screen app and your home screen app is usually system persistent, reducing number of shortcut will give extra RAM and reducing the required rendering process during scroll.
Live Wallpaper just as the name said looks really nice and require extra memory and process of course.
Tuning via build.prop
Some value can be added and modified into build to increase the performance of X10.
dalvik.vm.heapsize=32m
This will change the maximum memory size per application. If you decrease the value, smaller application starts faster, but big application like games will prone to crash, if you increase the value too much, smaller application takes longer to start, but big application will extra gain benefit from less garbage collecting.
Reference: Test: How changing the max amount of memory per VM Heap can effect your ROM (Cyanogen)
windowsmgr.max_events_per_sec=60
This will change the maximum number of touch screen gesture events per second, the bigger the value, the smoother the scrolling will be
There still some more build.prop tweaks that you can do, but not all of them will be processed by X10 as each device behave differently.
reservation for more article to go
Nice clean guide, should help newcomers. Good work!
synlar said:
Nice clean guide, should help newcomers. Good work!
Click to expand...
Click to collapse
Thanks, but i am quite depressed after reading it my self and found that i make a lot of typo. Had to revise and revise again.. lol.
Nice piece of work there Xeviro..
Can you post your build.prop please i cant find the windowsmgr.max_events_per_sec=60 one in mine.
Wolfbreak said:
Can you post your build.prop please i cant find the windowsmgr.max_events_per_sec=60 one in mine.
Click to expand...
Click to collapse
That one you add by your self to you build.prop. If you look further in google, there still a lot of other build properties that you can set to Android.
There is another way to add and test build.prop instantly by using adb shell command "setprop key value" and "getprop key". Some property will take effect immediately, some require you to reboot.
How do you prove that the windowsmgr.max_events_per_sec=60 actually works? After applying that I tried input benchmark and it still showed 33hz.
ooidort said:
How do you prove that the windowsmgr.max_events_per_sec=60 actually works? After applying that I tried input benchmark and it still showed 33hz.
Click to expand...
Click to collapse
Ok, i just checked, that for this build.prop property to take effect, you need to reboot the device first. I just test on my, giving 10 and 200 in value. With 10, the input benchmark showing less then 20hz most of the time, while with 200 it gives me 40hz+.
Also you can see if you scroll the app list with 10 and 200 value, you can see the difference.
xeviro said:
Ok, i just checked, that for this build.prop property to take effect, you need to reboot the device first. I just test on my, giving 10 and 200 in value. With 10, the input benchmark showing less then 20hz most of the time, while with 200 it gives me 40hz+.
Also you can see if you scroll the app list with 10 and 200 value, you can see the difference.
Click to expand...
Click to collapse
I definitely notice the difference between 10 and 200, but it still doesn't go above 33hz... Maybe it's the framerate cap doing it's thing?
xeviro said:
Thanks, but i am quite depressed after reading it my self and found that i make a lot of typo. Had to revise and revise again.. lol.
Click to expand...
Click to collapse
Good write up! I was actually going to say something about the typos/errors, because I'm a jerk, but, you noticed them too, so I feel satisfied.
I hope people will read your little intro about RAM and realize a task killer's real purpose is to kill rogue services that kill battery.
xeviro said:
That one you add by your self to you build.prop. If you look further in google, there still a lot of other build properties that you can set to Android.
There is another way to add and test build.prop instantly by using adb shell command "setprop key value" and "getprop key". Some property will take effect immediately, some require you to reboot.
Click to expand...
Click to collapse
But where do i need them to add? At Beginning or at End or Middle?
iead1 said:
Good write up! I was actually going to say something about the typos/errors, because I'm a jerk, but, you noticed them too, so I feel satisfied.
I hope people will read your little intro about RAM and realize a task killer's real purpose is to kill rogue services that kill battery.
Click to expand...
Click to collapse
Please forgive my typo and grammars, i life in country where people simplify their way of communication. I cannot talk proper now. hahaha
Wolfbreak said:
But where do i need them to add? At Beginning or at End or Middle?
Click to expand...
Click to collapse
Anywhere
xeviro said:
Please forgive my typo and grammars, i life in country where people simplify their way of communication. I cannot talk proper now. hahaha
Anywhere
Click to expand...
Click to collapse
If i add this to the end of my build.prop my phone does not accept SIM unlock code anymore .... ??
EDIT: Strange, second time it worked ... btw. what is the default value ?
Ive added dalvik.vm.heapsize=32m to see what diff it will make and well..
wow.. it killed my phone.
It will show sony ericsson on the screen when you turn it on and just stay there!
So yeah... how can i fix this?
It's bricked, you'll need to reflash the software!
:-(
OP- Great thread, thank you!
Post on my Rooted 2.1 X10i using Tapatalk Pro and Swype
Yeah i knida noticed...
fixed now but im not trying that heapsize thing again..
Anyone here have the original/untouched nordic build.prop? I'm really appreciate it if you share it here. ^_^
Sent from my Xperia X10i (2.1 and rooted) using XDA app
Seansmit17 said:
Ive added dalvik.vm.heapsize=32m to see what diff it will make and well..
wow.. it killed my phone.
It will show sony ericsson on the screen when you turn it on and just stay there!
So yeah... how can i fix this?
Click to expand...
Click to collapse
Seansmit17 said:
Yeah i knida noticed...
fixed now but im not trying that heapsize thing again..
Click to expand...
Click to collapse
Its working correctly in my phone, and this heapsize settings is the most common one in android modding. you go check google and see the results.
I also attached build.prop from my phone.
This is a simple STARTER GUIDE to kernel features/parameters and everything you need to know about custom kernel goodies before you consider flashing them. Now that there are a few custom kernels out there for our device, you may want to know about these.
I’d be glad if you could help me complete this guide.
First of all I’d like to thank all kernel guys who put countless hours into this to bring us the features which I am going to explain soon.
Overview:
Post 1:
A.: What you want to know about the CPU/GPU of your device
B.: Custom Kernel Features
Post 2:
Coming Soon!!!
A: What you may want to know about the CPU/GPU of your device:
Galaxy Note 10.1 features a 1.4GHz Quad Core CPU (Exynos 4412) and a 400MHz GPU (Mali-400).
More Data will be added soon.
B.1: CPU/GPU/IO Features which comes with Custom Kernels:
OC/UC (As for OverClock/UnderClock):
As you may know, CPU or any other processing unit features a clock frequency. Over/Under Clock simply means raising/decreasing the clock frequency of CPU.
Reason: Why would one need to overclock? Because one needs more processing power. For example if you want to experience smoother gameplay when playing high-graphic games.
Why would we need underclock? Higher processing power demands more battery. So underclocking helps us, reserve more battery. As for HOX, searching internet and texting don’t need much of processing power. So we can limit the processing power and save battery during low use of our device.
•Note1: OC/UC is not limited to CPU. GPU is also capable of OC/UC. And the interface for that is NOT available in the current custom kernels of Note 10.1.
•Note2: Gamers may not use GPU UC. Limiting GPU processing power impact significantly on your gaming experience.
UV (As for Undervolt):
Every frequency of a processing unit, demands a certain amount of power to be supplied. Undervolting to put it simple means decreasing the voltage of a certain frequency (or all of them).
Reason: The more voltage CPU/GPU gets, more heat will be generated. So mainly we UV to decrease the generated heat of CPU/GPU.
•Note1: One Frequency needs a certain minimum amount of voltage to perform correctly and the system be stable. Undervolting more than a certain amount of voltage will cause system instability.
•Note2: UV improves battery life by using less power. See this.
CPU Governors:
Frequency scaling is the means by which the Linux kernel dynamically adjusts the CPU frequency based on usage of the device. Governors refer to schemes which dictate to the kernel how it should do these adjustments. (From rootzwiki)
To put it simple, Governors are the way that CPU frequency is adjusted according to the demand of operating system.
Selecting a proper governor for your CPU is crucial to the performance and battery preserving of your device. For example if you are low using your device you may use a more battery friendly governor and if you want to play games you may use a more power consuming performance governor.
•Note: See Droidphile’s Great Guide about Governors to be familiar with each one of them and the ones that you should use in different situations here.
I/O Schedulers (As for Input/Output):
Input/output (I/O) scheduling is the method that computer operating systems use to decide which order block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'. (From Wikipedia)
To put it simple, Schedulers are the way reading and writing to the SD card is managed.
The same things that is said in the Governors part is applied here, too.
•Note: See Droidphile’s Great Guide about Schedulers here.
ReadAhead buffer size:
In terms of reading data from SD card, there is a cache which is used as a buffer. The size of that cache is readAhead buffer size. The size has a direct impact on your reading speed of your SD. So giving it a right amount is crucial.
File System “X” R/W (As for Read/Write):
Android by default doesn’t support all the File Systems (What are file systems?! See here). So some kernels may add certain file system R/W. The most popular unsupported file system is NTFS.
B.2 Features of Custom Kernels (AKA Goodies!!!):
MultiCore PowerSaving:
This feature try to group up tasks in the least cores possible. To put it simple, it will focus in using least cores for your tasks to be done. This means less cores are active and so more battery life. Also this will decrease performance.
•Note: To enable use TricksterMod app. 0 for disable and 2 for the most aggressive.
CIFS:
In order to manage your cifs/nfs network shares on your Android device you need the proper and working modules. And so you can mount/unmount your network accessible file resources and access your data.
B.3 Other Features:
Init.d Support:
There are some scripts that run every time your device boot up which are located in /etc/init.d Those are called init.d scripts. One of the most popular init.d scirpts that is available for Note 10.1 is this.
Eco Mode - NEW:
Eco Mode is an optimized dual core solution for quad-core SOC (System on Chip) like the Qualcomm S4-pro. This should allow for Maximum battery life without sacrificing performance. - Paul Reioux
TCP Congestion Control:
The choices in this section, address how the operating system kernel manages flows of information in and out of the kernel, which is at some level the "switchboard operator" of your handset. More info here.
Better to leave this options as is. Cubic or Westwood as the default of your kernel.
Dynamic FSync - NEW:
fsync is a system call in Unix/Linux. "man fsync" says:
fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).
Click to expand...
Click to collapse
So it's something embedded in programs after a related set of write operations to ensure that all data has been written to the storage device. The bolded part is what makes it interesting for some to disable it - "The call blocks" means the calling program waits until it's finished, and this may create lag. The downside is that if the system crashes, the data on the storage devices may be inconsistent, and you may lose data. (From here).
Dynamic FSync, makes it possible for fsync operation to be asynchronous when the screen is on, and synchronous when the screen is off. And what does asynchronous mean? Means OS issues fsync call, but not necessarily immediately at commit time for each transaction. It delays the FSync call for a certain amount of time. In case of a crash, the transactions not yet sync'ed in the last delay time before the crash may be rolled back, but the state of the data is always consistent. (From here).
zRAM:
In order to explain zRAM more precisely first we need other terms defined clearly:
Swap can be compared with the swap file on Windows. If the memory (RAM) is almost complete, the data which is not used actively (ex. background applications) will be stored on hard drive so as to re-evacuate RAM free. If required, this data is then read back from there easily. This will preserve performance with no lose at multitasking (the main reason we use swap).
In zRAM unnecessary storage resources are compressed and then moved to a reserved area in the fixed RAM (zRAM). So in other words, zRAM is a kind of swap in memory. As the data is compressed not much memory needs to be preserved as zRAM. However, the CPU has to work more because compressed data has to be unpacked again when it is needed). The advantage clearly lies in the speed. Since the swap partition in RAM is much faster than this is a swap partition on a hard drive.
In itself a great thing. But Android does not have a swap partition, and therefore brings Android ZRAM under no performance gain as would be the case with a normal PC. (From here with some editing.)
Click to expand...
Click to collapse
What we need to know essentially lies here:
zRAM off = Low use data will be stored the way they are in the memory. This will cause no extra load on CPU, yet need more RAM.
zRAM on = Low use data will be stored compressed in the memory. This will cause extra load in CPU as to store or restore data, yet preserve more Free RAM.
The main use of zRAM is when you are using a heavy ROM that eats up all your RAM. This will allow multitasking to be more functional. On light ROMs, or for those who don't multitask much, this is not necessary.
Note: Also there are methods to use a part of internal memory as Swap space. This is not as fast as zRAM. But no RAM will be used at all and CPU load is less. Though I am not sure that this has been brought to our device yet. Will add more data soon on this part.
Work in progress, will add more info soon.
Reserved for OP
csec said:
•Note2: UV does not impact battery life (or it is not noticeable).
Click to expand...
Click to collapse
First of all, I would like to praise this guide for its information and depth, secondly I would like to help improve it;
emprize said:
the only different for me is temperature, for battery saving, always not noticeable for me, placebo effect most likely
Click to expand...
Click to collapse
AndreiLux said:
This is a nonsensical argument, temperature aka heat, is power. If you are getting a less heated phone, then your battery life is improving. If this wouldn't be the case then you are holding the solution to the world's energy problems in your hands.
Click to expand...
Click to collapse
just thought i would share some thoughts of a well respected and knowledgeable developer.
http://forum.xda-developers.com/showthread.php?p=36723175#post36723175
Regards
Jack
JSale said:
First of all, I would like to praise this guide for its information and depth, secondly I would like to help improve it;
just thought i would share some thoughts of a well respected and knowledgeable developer.
http://forum.xda-developers.com/showthread.php?p=36723175#post36723175
Regards
Jack
Click to expand...
Click to collapse
Wow, that was hell of an argument. Seems to be theoretically true. What I referred to in above is real life experience with my phone and according to kernel guys down at HOX forums.
However the information was really interesting. I will add it to the OP.
Thanks.
Sent from my GT-N8000 using Tapatalk HD
Recently Added to the OP:
- Eco Mode
- Dynamic FSync
zRAM added to the guide.
This thread is for the fortunate subset of 5th Gen Fire devices that are rooted and rocking a custom ROM. It should also work on rooted FireOS (5.3.1 and below) that have both ads and OTA updates blocked.
There have been numerous posts regarding uneven performance while multitasking along with sluggish response after waking the device from a long slumber. Most recognize this is due to excessive swapping associated with limited user addressable RAM. While there are a number of incremental 'tweaks' that can marginally improve this behavior my objective was to realize a more substantial improvement with minimal effort, knob turning and side effects. To date I have realized the benefit (minimal lag; responsiveness approaching devices with twice the RAM; woohoo!) but still working on the automation that will make it largely transparent. Lacking the time to work on the latter I thought it best to toss out the high level config and let others, if interested, work through both validation and implementation details.
As an aside, I have used the same technique on a 2nd gen HD running CM 11 that had been shelved for many months due to the same issues. It now hums along at a respectable pace and is once again a joy to use.
The secret sauce is simple: expand zram space allocation and add a small, secondary swap file in a normally unused location in permanent storage.
Tools (or adb/shell/terminal commands for those with furry chests):
- EX Kernel Manager (EXKM) or other tool/technique that can manage zram parameters (note: I find current builds of Kernel Adiutor too unstable for this work)
- Apps2SD Pro or other tool/technique that can create/manage traditional swap files and swap space priorities
- BusyBox Installer (v1.27.2+) or other tool/technique to insure startup scripts are properly executed
- L Speed (optional) - for ease of implementing a few discretionary performance tweaks
- DiskInfo PRO (optional) - visualize partition utilization
- RAM Truth (optional) - simple app to visualize RAM utilization
Technique (highly abbreviated):
- boot device to rooted ROM; install above tools or equivalents
- use EXKM to resize zram to 128 MB (note: zram must be temporarily disabled)
- use Apps2SD to:
* add a static, 128 MB swap file in the cache partition which remains largely unused with custom ROMs
* important: reassign swap file priorities (button at top right): 0 for the static file; 1 for zram
* increase swappiness to 100 if necessary (EXKM can also be used to set swappiness and other VM parameters)
* verify both swap spaces are enabled via sliders
Note to geeks: I understand how swappiness, vcache pressure and other virtual memory tunings really work; let's not debate that here. Same with the merits of running a static swap file in combination with zram or the 'dangers' of placing that file in the volatile cache partition. We're talking a hand held device with very modest resources...not the server room with a 99.9x SLA. Yes, zswap would be better. However ...
Optional tweaks:
- use EXKM or L Speed to set LMK parameters to: 24, 32, 40, 48, 56, 64
- use EXKM or L Speed to set write deferral (aka 'laptop mode') to 5 sec
- toggle KSM off/on in L Speed (sets performance enhancing parameters)
- with zram disabled enable zram tweak in L Speed which will establish a 96 MB space along with other optimizations; I find the smaller size ideal for my workflow; YMMV zRAM size can be set with EXKM or another kernel manager.
Challenges:
While the options exist none of the tools noted above can reestablish custom zram space or automatically create a static swap file on boot. I believe this is a kernel issue but have not ruled out interference by Lineage 12.1 which is the ROM I have been testing with. Unfortunately, I lack the time (and quite frankly motivation) to toss Nexus or another ROM on to a spare device to verify the culprit. I might do a bit more testing my my HD 7 which uses a different kernel and ROM. --> Turns out an old version of BusyBox was the culprit; updating to 1.27.2 solved the problem allowing the suggested configuration to be automatically reestablished on reboot. I added my favorite BusyBox installer to the prerequisite tools.
Another issue is the potential for maintaining 'stale' annon pages in zram for a period of time but that's a left field item that probably won't effect most users. A quick fix is occasionally swiping away all apps.
Provide discussion/feedback in this thread. I may or may not respond depending on available time. I love a deep dive (shared above) but once the goal has been reached my interests move elsewhere.
Edit: struck-out references to L Speed after developer/maintainer acknowledged "cooperation" with Kingo Root team (borderline malware).
Quick follow-up: I continue to enjoy benefits noted in the OP with a dual cache configuration. Device remains responsive after waking and typically returns to 'full' performance within a few seconds. I can easily switch between a handful of apps (browser, mail, Play Store, XDA labs, etc) with minimal lag and context preservation; no reloading web pages after switching away. No notable impact on battery life. Really no disadvantages at all - at least with my work flows.
Regardless of tuning one has to keep in mind the modest hardware resources on Fire 7s. Load up a game or two or a couple heavy Amazon/Google apps and things go south pretty quick. That said, responsiveness far better than any stock config, even when the device is clearly overburdened.
Another quick note. Simply adding a classic swap file (suggest 128 GB) to the largely unused cache partition can yield a decent improvement in multi-tasking performance without the complexity of tinkering with zRAM. All steps can be accomplished with the free tool Apps2SD or equivalent. Happy to document if there is sufficient interest.
Note: Be sure to change zRAM swap priority to "1" so it receives preferential treatment over the classic swap file. zRAM will almost always be faster than classic swap but there is only so much if it. The swap file will be used once zRAM is fully utilized (not entirely accurate but generally true).
FWIW - depreciated references to L Speed app in OP after developer acknowledged "cooperation" with Kingo Root team. While nefarious behavior is unlikely there are other options that avoid any potential conflict of interest.
Davey126 said:
...
Technique (highly abbreviated):
- boot device to rooted ROM; install above tools or equivalents
- use EXKM to resize zram to 128 MB (note: zram must be temporarily disabled)
- use Apps2SD to:
* add a static, 128 MB swap file in the cache partition which remains largely unused with custom ROMs
* important: reassign swap file priorities (button at top right): 0 for the static file; 1 for zram
* increase swappiness to 100 if necessary (EXKM can also be used to set swappiness and other VM parameters)
* verify both swap spaces are enabled via sliders
Note to geeks: I understand how swappiness, vcache pressure and other virtual memory e)
Click to expand...
Click to collapse
When you say Cache partition for the swap file are you referring to "/cache" or the second partition for app2sd?
rjmxtech said:
When you say Cache partition for the swap file are you referring to "/cache" or the second partition for app2sd?
Click to expand...
Click to collapse
"/cache" partition which resides on faster internal storage. Anything on external storage will be significantly slower due to interface limitations.
@Davey126 it has been about a day or two and I can confirm that by following these instructions it has brought new life into my KFFOWI 5th gen. This paired with some L Speed Tweaks (even though you say not to trust them, I opted to use it for a few performance tweaks) and the Lineage ROM from @ggow makes my user experience on the device quite pleasing.
rjmxtech said:
@Davey126 it has been about a day or two and I can confirm that by following these instructions it has brought new life into my KFFOWI 5th gen. This paired with some L Speed Tweaks (even though you say not to trust them, I opted to use it for a few performance tweaks) and the Lineage ROM from @ggow makes my user experience on the device quite pleasing.
Click to expand...
Click to collapse
Thanks for the feedback.
As for L Speed I don't distrust the current developer/maintainer but no longer feel comfortable providing an implicit endorsement. Who you associate with makes a difference IMHO. Each person needs to make their own call. There is no magic in L Speed; it simply offers a convenient UI to various well publicized system 'tweaks' that can be implemented using other tools/techniques.
Davey126 said:
Optional tweaks:
- use EXKM or L Speed to set LKM parameters to: 24, 32, 40, 48, 56, 64
- use EXKM or L Speed to set write deferral (aka 'laptop mode') to 5 sec
- toggle KSM off/on in L Speed (sets performance enhancing parameters)
- with zram disabled enable zram tweak in L Speed which will establish a 96 MB space along with other optimizations; I find the smaller size ideal for my workflow; YMMV zRAM size can be set with EXKM or another kernel manager.
Click to expand...
Click to collapse
Thanks for the guide, it already seems to have helped a lot with smoothness but I wanted to know how to set these options using EXKM.
I'd never heard of the app before today and I've had a good look through the menus but can't seem to find somewhere to set these values. I'm guessing these are the usage % values used by the CPU governor to jump up and down power states?
NeuromancerInc said:
Thanks for the guide, it already seems to have helped a lot with smoothness but I wanted to know how to set these options using EXKM.
I'd never heard of the app before today and I've had a good look through the menus but can't seem to find somewhere to set these values. I'm guessing these are the usage % values used by the CPU governor to jump up and down power states?
Click to expand...
Click to collapse
No, governor tunning is a different beast not addressed in the OP (although I do that on some higher end devices).
With regard to EXKM:
- LMK values can be set under memory -> low memory killer
- KSM toggle can also be found in the memory section
- it appears laptop mode can not be set in EXKM (not that important)
As an alternative to laptop mode you can twiddle 'dirty ratio' and 'dirty background ratio' in EXKM. Suggest setting to 30 and 15, respectfully.
Edit: you may also want to take a peek at Kernel Adiutor (correct spelling). While I find it a bit flaky it exposes more controls vs EKKM and costs less too.
Davey126 said:
No, governor tunning is a different beast not addressed in the OP (although I do that on some higher end devices).
With regard to EXKM:
- LMK values can be set under memory -> low memory killer
- KSM toggle can also be found in the memory section
- it appears laptop mode can not be set in EXKM (not that important)
As an alternative to laptop mode you can twiddle 'dirty ratio' and 'dirty background ratio' in EXKM. Suggest setting to 30 and 15, respectfully.
Edit: you may also want to take a peek at Kernel Adiutor (correct spelling). While I find it a bit flaky it exposes more controls vs EKKM and costs less too.
Click to expand...
Click to collapse
Ah, LMK, not LKM. Thanks again.
Also, just a small suggestion but wouldn't it be better to remove the references to L-Speed and leave an edit message at the bottom rather than having the red, striked through text in the middle?
NeuromancerInc said:
Ah, LMK, not LKM. Thanks again.
Also, just a small suggestion but wouldn't it be better to remove the references to L-Speed and leave an edit message at the bottom rather than having the red, striked through text in the middle?
Click to expand...
Click to collapse
Thanks for noting LKM/LMK typo in OP - fixed that.
I will likely clean-up the OP at some point as there are other refinements (eg: tweaking dirty ratios) that may prove beneficial to a larger community.
Davey126 said:
Thanks for noting LKM/LMK typo in OP - fixed that.
I will likely clean-up the OP at some point as there are other refinements (eg: tweaking dirty ratios) that may prove beneficial to a larger community.
Click to expand...
Click to collapse
I was wondering what differences need to be made for a 7th gen hd 10. I know this guide is written for a 5th gen (1gig RAM, 8 gig drive), but I have a 7th Gen (2gig RAM, 32GIG drive) with 2gig zram (priority 1) and 4 gig swap on the /data partition (priority 2). What would be the best LMK values? Also, is it ok to have the swap on /data vs /cache (my /cache only has 400mb)?
Thanks for any help!
edit: in the OP, it says to set laptop mode using L-speed, and then L-speed is crossed out (I understood why), but no alternative is listed for doing this. I just wanted to add that you can use kernel adiutor to change laptop mode. It's on virtual memory settings.
mistermojorizin said:
I was wondering what differences need to be made for a 7th gen hd 10. I know this guide is written for a 5th gen (1gig RAM, 8 gig drive), but I have a 7th Gen (2gig RAM, 32GIG drive) with 2gig zram (priority 1) and 4 gig swap on the /data partition (priority 2). What would be the best LMK values? Also, is it ok to have the swap on /data vs /cache (my /cache only has 400mb)?
Thanks for any help!
edit: in the OP, it says to set laptop mode using L-speed, and then L-speed is crossed out (I understood why), but no alternative is listed for doing this. I just wanted to add that you can use kernel adiutor to change laptop mode. It's on virtual memory settings.
Click to expand...
Click to collapse
It appears you have priorities reversed. Higher values receive preference. The magnitude of the difference is irrelevant. zRAM is considerably faster than eMMC based storage; the latter should only be used when zRAM is exhausted or momentarily unavailable for whatever reason.
The container sizes also seem excessive. 2 GB of zRAM effectively leaves no uncompressed memory on a HD 10 which is highly inefficient. I wouldn't go over ¼ available RAM or ~½ GB. Toss in a 500 MB of eMMC based (overflow) swap file and you're good to go. If you regularly use more than 1 GB of swap on a relatively low end Android device then something else is amiss.
I am aware Kernel Adiutor can set laptop mode but did not want to introduce another tool into the mix...especially one that has demonstrated inconsistent behavior. FWIW - recent testing suggests 1-2 sec may be a better choice vs the 5 sec mentioned in the OP as the latter may trigger lockouts during sustained writes (eg: large file download on a fast connection). I currently use 1 sec and happy with the results. I will likely update the OP with this info once satisfied that the benefit is worth the effort.
All things being equal I see no reason to change LMK values suggested in the OP. Especially given the availability of zRAM and swap.
Thanks for these instructions, Davey126!
I just tried this process on my 5th Gen Fire 7" which I recently installed with the LineageOS ROM. I was not familiar with the EX Kernel Manager and Apps2D Pro tools, but it was reasonably clear how to make the settings changes you recommend.
I added the 128Mb swap under /cache and increased the zram swap to 128Mb, setting it to priority 1. Maybe it's my imagination but my device does seem a lot snappier when switching between running applications, and better at returning to previously displayed data in applications instead of reloading pages.
Cheers!
Matrey_Moxley said:
Thanks for these instructions, Davey126!
I just tried this process on my 5th Gen Fire 7" which I recently installed with the LineageOS ROM. I was not familiar with the EX Kernel Manager and Apps2D Pro tools, but it was reasonably clear how to make the settings changes you recommend.
I added the 128Mb swap under /cache and increased the zram swap to 128Mb, setting it to priority 1. Maybe it's my imagination but my device does seem a lot snappier when switching between running applications, and better at returning to previously displayed data in applications instead of reloading pages.
Cheers!
Click to expand...
Click to collapse
Thanks for sharing first impressions. Time will tell if the benefits are durable; certainly have been for me with no adverse side-effects.
Another suggestion to reduce wake lag: install Greenify (or similar tool) and add commonly used apps to the action list even if not flagged as background abusers (you may need to override Greenify's sensible defaults via the gear icon). This prevents multiple apps from becoming simultaneously 'active' on wake which is a huge contributor to lag on lower end devices with limited resources (CPU and RAM). Hibernated apps will launch when needed with minimal delay and NO loss of context. Works a treat.
Be sure to add your favoriate browser, mail, messaging and social media apps to the hibernation list as all like to 'check in' after a long slumber.
Although Greenify can auto-hibernate apps on most devices (works best with Xposed Framework) I use an automated approach that invokes Greenify's widget when the screen goes off. There's still some momentary lag on wake but the device remains responsive which is a huge improvement.
Hi Davey126,
thx for the guide, it seems to work awesome.
However, i have the one problem thats the settings in EXKM regarding to "zRAM Size", "dirty ratio" and "dirty background ratio" are lost after rebooting the device. Is there a way to make the settings reboot proof? Interestingly for the "LKM" settings there is an option "Apply at bootime", which does the trick for me, but only for the LKM options.
Kind regards,
Stephan
IronMan1977777 said:
Hi Davey126,
thx for the guide, it seems to work awesome.
However, i have the one problem thats the settings in EXKM regarding to "zRAM Size", "dirty ratio" and "dirty background ratio" are lost after rebooting the device. Is there a way to make the settings reboot proof? Interestingly for the "LKM" settings there is an option "Apply at bootime", which does the trick for me, but only for the LKM options.
Kind regards,
Stephan
Click to expand...
Click to collapse
Likely BusyBox is missing or outdated. Try installing this (I use the pro version).
Davey126 said:
Likely BusyBox is missing or outdated. Try installing this (I use the pro version).
Click to expand...
Click to collapse
Ok. I bought BusyBox Pro and updated to Version 1.28.1-Stericson. Still all settings in EXKM besides LMK get lost after rebooting the device ...
IronMan1977777 said:
Ok. I bought BusyBox Pro and updated to Version 1.28.1-Stericson. Still all settings in EXKM besides LMK get lost after rebooting the device ...
Click to expand...
Click to collapse
- verify BusyBox is property installed w/no conflicting builds
- uninstall/reinstall EXKM
- test if behavior can be duplicated with another (free) kernel manager like KA
Hello, i thought id help people who have low spec computers and who want to perform a clean install on there machine. Firstly obtain a copy of windows 10 preferably 32 bit. With a keycode. This tutorial is aimed at machines with 2gb of ram or less eg 1 gb. It helps if the processor supports HT (Hyper Threading) or is a dual core processor to be able to cope with the load and instructions of the cpu. Ive installed on a pentium 3.ghz supporting HT. I know windows 10 supports lower cpu speeds ive also installed on intel atom 1.6ghz too( Netbook). I have some earlier Pentium 4 cpus e.g 2.4-2.6ghz and will be trying lower spec cpus and will update as i go along. To improve performance some of the services in windows 10 will need to be shut down. There are 4 services that impact the quite significantly.
1: Background Intelligent transfer.
2: Superfetch.
3:Themes.
4: Windows Update.
Also Chrome is bad for eating up memory as well. Windows 10 will really struggle on low amounts of memory if these services are not disabled. The main culprit being windows update.
How to close these services down.
Go to Control panel - Administrative tools- Services- Scroll down the list to find each one then disable each one. And stop each service. Restart your pc and press control -alt-del then select task manager click on the 4th tab along for performance here you can monitor your cpu load, amount of memory being used and check your disk useage. Its also advisable to enable "Do not check for windows update. As you will get reminders to check. No updates will be applied to your pc. If you do require updates, the update service can be enabled again. But i would recommend disabling afterwards. I hope this will help some members. If you feel it has helped donations are very welcome thank you.
completely useless and potentially dangerous....
Enlighten me Midral how can it be useless and dangerous. Comments but with no actual reasons as to why. Easy to critsize isn't it. Tell me then how would you run windows 10 with 1-2 gb of memory and by letting all the services run. How can it be dangerous? Id love to know and id like to know your work arounds. Id have thought its more dangerous by letting everything run as youll over load your memory, cpu and maybe it will overheat certainly freeze and or crash.
You need to backup your sarcastic comments Midral. What knowledge or experience do you have and don't start researching on google. What contributions have you made to the forums? I'd love to know
Midral said:
completely useless and potentially dangerous....
Click to expand...
Click to collapse
Not to me... first thing I do is disable these "services." Seems that these GD updates break more than they fix. On two of my budget tablets I wound up reinstalling Windows and immediately disabled updates. Prestochange-o!! No more trouble. I use Winaero Tweaker and Auslogics Boostspeed to fine tune and clean, and I use tenforums.com for tutorials on how to debloat all of the useless junk from windows.
Rich
Thank you Rich, as you say if you ran all the services its cripples the rescources. On low end equipment you have to disable services. I also use group policy to prevent the windows updates from renabling after rebooting. otherwise you end up with 100% cpu and or disk useage making it impossible to even browse your system. But Midral doesnt seem to grasp this as i say its easy to make sarcastic comments. It would be interesting to see his work arounds for low end budget tablets. laptops and pcs.
Another tip: Use tablet mode. The system uses the resources much better.
Hi Essential Phone owners,
Can someone confirm that the Essential Phone has set dalvik.vm.heapsize to 36m instead of... 512m?
The build.prop in the vendor partition of the phone has this line:
dalvik.vm.heapsize=512m
// line 29
But the build.prop in the system partition has:
dalvik.vm.heapsize=36m
// line 68
Any devs know which one gets applied last? I think at the current state it would be heapsize=36m which is unusual.
For anyone that can edit build.prop on their own phone you can try this,
1. Remove dalvik.vm.heapsize=36m in system's build.prop
Or
2. Add dalvik.vm.heapsize=512m at the bottom of the system's build.prop
:angel:
this is extraordinarily interesting due to the fact that ive seen reports on reddit claiming this makes scrolling smoother. i deleted the heapsize=32 line and noticed maybe a slight difference. nothing night and day but a small improvement. granted i am running stock with elementalX kernel but its still worth noting that in my case it seems to yield a slight improvement
JBlaze05 said:
this is extraordinarily interesting due to the fact that ive seen reports on reddit claiming this makes scrolling smoother. i deleted the heapsize=32 line and noticed maybe a slight difference. nothing night and day but a small improvement. granted i am running stock with elementalX kernel but its still worth noting that in my case it seems to yield a slight improvement
Click to expand...
Click to collapse
Where did you find reports on reddit?
Anyways thanks for your input!
TFutoMaki said:
Where did you find reports on reddit?
Anyways thanks for your input!
Click to expand...
Click to collapse
this would be the thread
This means nothing...
su
getprop|grep heapsize
It's all placebo
Heap size and scrolling? Wtf. No, just no. I have a thread on here that actual helps with the scrolling. Add the following to your build prop in /system to improve scrolling lag and stutters.that other stuff would do nothing.
#Property to enable touch optimizations
persist.vendor.qti.inputopts.enable=true
persist.vendor.qti.inputopts.movetouchslop=0.6.
The 0.6 can be changed to your liking. 6 works well. Don't go past 8 or **** gets weird.
Thanks you all, I got with me the Essential phone now so yeah seems like it is system build.prop, and then vendor build.prop applies over it. Interesting stuff that I should remember
Dalvik heapsize
36mb heap size is use before for low memory devices that have only 512mb of physical memory or ram, Running in gingerbread os etc. that uses only small amount of physical memory and not much features added on the Android operating system, The answer to your question is 36mb heap size is not gonna work in newer Android devices and it can cause bootloop, because the newer Android Operating System requires higher usage of physical memory for full functionality.
"vendor_build.prop and system_build.prop Is the same list in functionality they only have different location, the system combining them in to one build.prop, to check your full system combined build.prop install terminal emulator and enter- "getprop"
vendor.prop is should be for Rom versions and the system.prop is for manufacturer default Android features and device features configuration.
marvinxxx said:
36mb heap size is use before for low memory devices that have only 512mb of physical memory or ram, Running in gingerbread os etc. that uses only small amount of physical memory and not much features added on the Android operating system, The answer to your question is 36mb heap size is not gonna work in newer Android devices and it can cause bootloop, because the newer Android Operating System requires higher usage of physical memory for full functionality.
"vendor_build.prop and system_build.prop Is the same list in functionality they only have different location, the system combining them in to one build.prop, to check your full system combined build.prop install terminal emulator and enter- "getprop"
vendor.prop is should be for Rom versions and the system.prop is for manufacturer default Android features and device features configuration.
Click to expand...
Click to collapse
You answered a 2 year old post...