Zram and Swappiness - Galaxy S III Q&A, Help & Troubleshooting

Im specifically after an answer for the swappiness tbh.
Im using Yank kernel and it allows zRam which i usually set at about 300. The swappiness part i dont understand and cant really find any info on it, it has settings going up in steps of 10 from 60 to 100. I set it at 80 but thats only because its in the middle.
Could someone explain to me or link me to something, that isnt too technical, about what these steps are for and what they do for it?

It just means how aggressive it is at forcing things into zram. The higher the number (100), the more forceful it is to use the 300 you set as zram over the normal ram.
Swappiness is usually a term to describe swap bias. As above but towards a swap partition or file. Technically zram and swap aren't the same but the term swappiness works
This is really over simplified but I think it should be sufficient.
Sent from my GT-I9300 using Tapatalk 2

Cheers that'll do me, at least it gives me an idea and I can have a play about with it

Related

Can you fry your CPU with SetVsel

Hi,
I read through approx. 50 pages of text and didn't find an answer:
Is there some kind of prevention to enter numbers like 6000mhz (eg when you meant 600) ?
Same with the voltage: could I enter and apply a critical value ? I tried it with "5" which lead to instant reboot.
Also: I can't find any explanation on what sd card speed fix does ?
Also: What does Jit do ?
THX
Low vsel will really cause reboot as it doesnt getr enough juice to run, on the other hand if you set it to 6000 but didnt change the vsel imo it would again reboot. That is if you accidentally put it, but if you deliberately want to try vsel 1000 @ 6000mhz, that I don't know,run test underwater to prevent meltdown. Good luck
Sent from my MB525 using XDA App
but it would immediately die and would not explode right ?
I think the VSel is limited to a max value of 78, or 80, or the limitation comes from the kernel, something like this.
Also there is a limitation from ARM to prevent hardware damage, there are a lot of failsafe mechanism built inside the hardware, beside the software.
maxi2mc said:
I think the VSel is limited to a max value of 78, or 80, or the limitation comes from the kernel, something like this.
Also there is a limitation from ARM to prevent hardware damage, there are a lot of failsafe mechanism built inside the hardware, beside the software.
Click to expand...
Click to collapse
No max vsel is 90. Max clock thats stable is 1380 MHz.
Sent from my MB525 using XDA App
Ok... so you can't really fry your hardware.
At worst it will die within a few hours/ days/ weeks ?

Quick SetCPU question.

Flashed Faux123's Kernel acouple days ago and have a question.
Does this Application need to be running for the voltage changes to work? What about for the profiles set?
Thanks.
i don't know the answer because i haven't flashed a kernel. the quickest and best answer is to try yourself. setcpu is in the market.
I know, but it's hard to tell and I really don't want to undervolt too much more because I don't wanna see a crash, although I have yet to experience one. I have it set at
Respectively:
-100
-100
-50
-75
-300
-300
-300
Seems stable with and without SetCPU on while spamming Quadrant standard benches and I cannot tell if the voltages are working or not. Those extra volts being taken away can greatly help my battery life, but if it's not working without the program on there is literally no way to tell. I use Advanced Task Manager a lot and it takes out SetCPU all the time.
Maybe someone with more experience of the program can help me out.
why do people undervolt it? Why wouldn't Faux undervolt when he created it? I don't touch the voltages, but not sure how you test if undervolting would hurt performance.
There is a bunch of responses to undervolting in faux's kernel thread in the dev forum. But long story short u can't have more than 100 m's between jumps when setting your undervolting, or it simply wont apply it. Example.
75
75
75
75
125
200
225
Sent from my MB860 using XDA Premium App
Phalanx7621 said:
There is a bunch of responses to undervolting in faux's kernel thread in the dev forum. But long story short u can't have more than 100 m's between jumps when setting your undervolting, or it simply wont apply it. Example.
75
75
75
75
125
200
225
Sent from my MB860 using XDA Premium App
Click to expand...
Click to collapse
Really? I'll adjust my settings. Can you show me where it says that -100 jumps won't be applicable?
Probably going to adjust it to
100
100
75
75
175
275
300
edit: It's stable after around 10 Quadrant runs. I'd still like where you found that information though.
Thanks
Phoneguy589 said:
why do people undervolt it? Why wouldn't Faux undervolt when he created it? I don't touch the voltages, but not sure how you test if undervolting would hurt performance.
Click to expand...
Click to collapse
Well, I've been overclocking computers for years and something I've learned is that the lower your voltage is, the less degraded the processor will be after awhile. Such as, if you overclock the voltage too high, overtime you would need more voltage to obtain the same speed. Same thing applies when overclocking graphics cards.
Edit: Anyways, why are people dodging the main question
no you shouldnt have to keep setCPU running. i believe the app is just changing some sysfs files, so its one and done till the next time you open and change more values.
LivingChampion said:
Really? I'll adjust my settings. Can you show me where it says that -100 jumps won't be applicable?
Probably going to adjust it to
100
100
75
75
175
275
300
edit: It's stable after around 10 Quadrant runs. I'd still like where you found that information though.
Thanks
Well, I've been overclocking computers for years and something I've learned is that the lower your voltage is, the less degraded the processor will be after awhile. Such as, if you overclock the voltage too high, overtime you would need more voltage to obtain the same speed. Same thing applies when overclocking graphics cards.
Edit: Anyways, why are people dodging the main question
Click to expand...
Click to collapse
Probably going to adjust it to
100
100
75
75
175
275
300
Bro, this setting is left 770-470 = 300 or 770 - 300 = 470mv ?

[Q] Fine tuning swap usage

Hey guys,
I have an HTC One V, which is a pretty low-mem device at 512MB RAM. I've been using a normal 256MB swap partition on my SD card with swappiness set to 100 and default minfree settings. This has already given me fantastic results, now I can switch between 4 running programs without having to reload any of them. Before the swap script 2 was the maximum, and even that wasn't always true. Basically I had no multitasking.
Now, I've been checking my memory usage in detail. It seems that when idle, there is about 80MB of free RAM, and around 80MB of swap space is being used. It seems that even though I have 256MB of swap space available, Android never really goes above using ~80. Is there a setting I can fine tune somewhere that would lead to better use of the swap space? From my limited understanding, it seems that in theory Android could store at least two or three more background apps on the swap partition instead of killing them. Which, of course, would lead to much better multitasking.
I'm also aware that using the full 256 megs might actually hurt performance, but I still want the OS to use more than 80.
Please don't flame me if this question has been asked before, I tried to search, but I only found threads discussing the value of vm.swappiness.
TRY TO USE KERNEL TUNER.
AS WELL AS INCREASE SWAPPINESS TO 128 MB.
BUT OS TAKES ONLY AS MUCH RAM IT WANTS U NO NEED TO WORRY THAT IT IS NOT PROPERLY UTILISED.
Hit thanks.....
caius112 said:
Hey guys,
I have an HTC One V, which is a pretty low-mem device at 512MB RAM. I've been using a normal 256MB swap partition on my SD card with swappiness set to 100 and default minfree settings. This has already given me fantastic results, now I can switch between 4 running programs without having to reload any of them. Before the swap script 2 was the maximum, and even that wasn't always true. Basically I had no multitasking.
Now, I've been checking my memory usage in detail. It seems that when idle, there is about 80MB of free RAM, and around 80MB of swap space is being used. It seems that even though I have 256MB of swap space available, Android never really goes above using ~80. Is there a setting I can fine tune somewhere that would lead to better use of the swap space? From my limited understanding, it seems that in theory Android could store at least two or three more background apps on the swap partition instead of killing them. Which, of course, would lead to much better multitasking.
I'm also aware that using the full 256 megs might actually hurt performance, but I still want the OS to use more than 80.
Please don't flame me if this question has been asked before, I tried to search, but I only found threads discussing the value of vm.swappiness.
Click to expand...
Click to collapse
Disclaimer: This is somewhat speculative.
The vm.swappiness is in principle what you are looking for, talking about Linux swap. Unfortunately, for you right now, the Andorid uses "application level swapping", i.e. the Android ActivityManager (userspace task) kills of app's when the memory gets low. Since Android normally don't utilize swapspace, there's a possibility ActivityManager doesn't looks at the size of the total virtual memory (including backed by swap), but only the physical memory installed. If so, it will continue killing app's at the same memory threshold as before, despite of the increased virtual memory size, hence not utilizing the increased virtual memory particularly well. This sounds as what you are describing.
You'll need to check the source ApplicationManager.java to examine the internals here.

Question: Android and zswap in kernel

I was recently trying out various kernels and hit one very intriguing feature in devil kernel. It allows you to set some memory out as zswap and change swappiness value of kernel. I googled and found lot of articles about zswap and linux kernel but absolutely no articles on how it impacts android performance.
So how does providing ram to zswap benefit android ?
Is it something which should be done on devices with 2 GB ram already ?
Does Fsync setting come into picture and does zswap increase chances of data loss ?
Zswap in Android
rApt0r7 said:
I was recently trying out various kernels and hit one very intriguing feature in devil kernel. It allows you to set some memory out as zswap and change swappiness value of kernel. I googled and found lot of articles about zswap and linux kernel but absolutely no articles on how it impacts android performance.
So how does providing ram to zswap benefit android ?
Is it something which should be done on devices with 2 GB ram already ?
Does Fsync setting come into picture and does zswap increase chances of data loss ?
Click to expand...
Click to collapse
Zswap compresses and swaps the pages to the swap area. Frees the available memory. Clearly differences can be observed with cat /proc/meminfo in Memfree section, Swaptotal and swapfree sections.
I have tested with 700MB ram in one android device, observed the clear difference.
I feel, it should be useful even for 2GB ram., because its used in the servers also.
PS: I have also started recently to work on this.
Thanks,

[DEV]Possible way of enabling mali400 dynamic memory use and allocation

I did find this https://groups.google.com/forum/#!topic/linux-sunxi/dYCL84IQH_Yù
In short: changing an option you can have mali do dynamic ram allocation that means it uses only ram that it REALLY needs, not some hardcoded number like 192. So when it is not needing so much ram, system has more free ram. Everyone likes having more usable ram right?
Pasting relevant parts
Siarhei Siamashka said:
After this fix, Mali400 GPU is configured to use up to 256 MiB of
normal memory when CONFIG_SUNXI_MALI_RESERVED_MEM is not enabled.
When CONFIG_SUNXI_MALI_RESERVED_MEM is enabled, it uses 64 MiB of
reserved memory and up to 192 MiB of normal memory (same as before).
Click to expand...
Click to collapse
and this
Mali has MMU and does not strictly need any physically contiguous
memory reservation. Most users will likely prefer more flexible
memory allocation instead of always wasting 64 MiB (even when Mali
is not used or needs much less).
CONFIG_SUNXI_MALI_RESERVED_MEM option is still available and can
be enabled if needed (for performance or some other reasons).
Click to expand...
Click to collapse
I wanted to ask if something like this is doable for our Xperia devices here that have a mali400 (U, Sola, Go and P). And if yes, how can we do this? Or at least try to see if it works.
Is it an option that has to be set in a config file when compiling kernel? Can it be set as build prop or init.d or whatever?
I'm not a dev and I don't have the environment/skill to compile anything so unless it is something easy I'm probably not going to make it myself.
High hopes for this though... :laugh:
@95A31 @percy_g2 @DevSwift1
I looked to our kernel codes now, it's possible to apply it but I don't know, it shouldn't be that easy :/
if the choice of pre-allocating ram for mali was because of "safety" reasons like avoiding potential hacks to pirate stuff or sidestep limitations imposed by licensing or whatever (like for example some of the Xposed Framework's modules that allow youtube content over HDMI port or whatever), it can just be a matter of disabling settings.
Or maybe they pushed it into production before the drivers were stable enough for dynamic ram allocation to work reliably.
Some people running linux on arm boards with a mali400 gpu already recommend to build kernels disabling that option to "maximize available memory".
http://www.malaya-digital.org/make-...-an-external-usb-hard-disk-over-your-network/
pasting relevant part here (note that this is for compiling linux-on-arm kernel and for a different device, stuff may or may not apply to our phones):
9] To maximize available memory, edit .config and look for the line having "CONFIG_CMDLINE". Then edit the line to become::
CONFIG_CMDLINE="[email protected] console=ttyS0,115200 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=8"
10] Look for CONFIG_SUNXI_MALI_RESERVED_MEM, CONFIG_MALI, and CONFIG_MALI400 in .config . Set them to "n" :
CONFIG_SUNXI_MALI_RESERVED_MEM=n
CONFIG_MALI=n
CONFIG_MALI400=n
Click to expand...
Click to collapse
Besides, I don't see why the heck a non-HD-resolution phone must keep 192 mb of dedicated gpu ram when anything else (desktop/laptop or console) can do perfectly fine with full HD resolutions and hardware accelerated h.264 decoding with a crappy card that has only 64mb of ram (and the hardware accelerator, of course).
Make more of a difference if we had a rom that actually used the leaked sources so it doesn't run like ****.
However I'd like this still as I don't game on my phone at all, so it's pointless for the gpu to use so much on mine.
Are there some devs working on it at the moment? It would be just great to have some MB's more RAM
I comparet our kernel with this one and they are totally different. AFAIK is not possible.
95A31 said:
I comparet our kernel with this one and they are totally different. AFAIK is not possible.
Click to expand...
Click to collapse
But it's still in AOSP todo, so we can hope? I think this can radically change our user experience, isn't it?
Our board uses only 32MB of RAM for Mali, not 64MB
Garcia98 said:
Our board uses only 32MB of RAM for Mali, not 64MB
Click to expand...
Click to collapse
then why we have only 392 mb out of 512? i know that some mbs are dedicated to the gpu, but 120mb to gpu????
alexhdkn said:
then why we have only 392 mb out of 512? i know that some mbs are dedicated to the gpu, but 120mb to gpu????
Click to expand...
Click to collapse
In Xperia U 15MB are used for memory debugger, 1MB for shared memory, 16MB for modem, 1MB for ISSW, 64MB (may vary) for hardware, 32MB are reserved for Mali and then 383MB (may vary) are available for the system
Regarding dynamic memory allocation, I don't think that using it would be a good idea, as it can lead to allocation failures, memory leaks and other logical errors. I'm sure that there is a reason why Igloo Community don't apply Mali dynamic memory allocation to Snowball
BTW, you can read here the opinion of a professional about dynamic memory allocation in real time systems: http://www.mentor.com/embedded-soft...10b6e1-f9e9-4d87-8c88-6ced717a9f7a?cmpid=8688 :good:
Said professional even goes further advising against the practice - but yet it landed on sunxi 3.4 branches, with dev even sounding almost shocked by the senselessness of the previous state of affair.
My educate guess is that if Igloo Community never lift a finger, is just because they were axed before such a secondary issue could become relevant, in the grand scheme of things.

Categories

Resources