After many tests I think that we really suffer from a lack of RAM. But the internal memory (NAND) should be the same speed as RAM I think. So why we don't use another 128Mb of NAND as additional RAM? A sort of swap part, but used as RAM and not as normal swap....
If someone related to the kernel would answer is it possible or not, it would be good)
DiMiK said:
After many tests I think that we really suffer from a lack of RAM. But the internal memory (NAND) should be the same speed as RAM I think. So why we don't use another 128Mb of NAND as additional RAM? A sort of swap part, but used as RAM and not as normal swap....
If someone related to the kernel would answer is it possible or not, it would be good)
Click to expand...
Click to collapse
Using it as RAM would propably require major changes to the kernel if it is even possible which I doubt it is. Using it as swap would be the possible alternative and I pretty sure that is very possible and would help performance but at a cost.
1. You would either have very little left for system and data or you would have to put system and/or data on the SD-card and that alone may make you lose anything you gain from putting swap on NAND.
2. I actually asked the swap-on nand question myself and well, we can't replace our NAND, at least not easily and swap is I/O intensive and intesive I/O will sooner or later wear out the NAND. So basicly this is not a good alternative unless you want to turn your phone into a paperweight sooner than you had planned.
So what we can do is using compcache and/or swap on SD-card. The easiest thing is to just enable some compcache. It uses RAM as swap and uses compression on the contents so we can hold more things in RAM that we would usually be able to. This means Android can keep more apps in "sleep" allowing for faster switching between apps but it will also decrease the possible amount of available RAM for the active app. I usually turn on compcache with the default setting which is to use 25% of the RAM for compressed swap. It might be placebo but IMHO it feels a it "smoother" to use after that.
Another alternative is to use a swap partition in the sdcard. Just using swap means you do not need to load any compcache kernel modules and there is no compression taking place so it's a good alterantive. However you need know your way around partitioning SD-cards to get this running so it's not as easy as just enabling compcache (assuming the build supports compcache).
For the really advanced you can enable compcache with backing swap. It means it uses a certain amount of compressed swap i RAM and when it runs out of space there it starts putting stuff on the SD-card swap partition. Once again, a bit tricky to setup but may be the best alternative.
Read more about it here: http://wiki.cyanogenmod.com/index.php/Compcache
kallt_kaffe said:
I usually turn on compcache with the default setting which is to use 25% of the RAM for compressed swap. It might be placebo but IMHO it feels a it "smoother" to use after that.
Click to expand...
Click to collapse
It make good effect: more applications can run simultaneously.
Hi again guys...
In Linux we have a SWAP partition for some time if RAM (Random Access Memory) will full OR for speed up applications by buffering in swap partition.
(Recommend Linux SWAP partition size: half of RAM)
so Android is Linux based and have kernel like Linux. Is it work to make a SWAP partition for SGS with swap file system?
You don't want that...
Android doesn't wipe RAM immediately anyway, so apps which are open and shutdown can be restarted again quickly (unless the RAM has been reused).
Also, apps on Android are designed to be shut down whenever free RAM runs out (its in the development guidelines that all applications should expect to be shut down at any time). Since most Android phones use high-speed NAND memory, when properly configured, apps load quicker too
The problem with swap is that it can lead to thrashing and loss of battery life. It's good for computers (because generally, you would rather lose performance and ensure you don't lose work), but on Android, applications should be killable at any time, and should have mechanisms to protect their work anyway.
It's probably possible to create a swap partition/file if you wish (try to swapon), but I foresee some potential side-effects, especially if you don't want to spend a lot of time managing memory manually.
i didn't think about battery life.
Thank you so muchhhhhhhhhh
I was actually exploring this option last night and stumbled that the kernel does allows swapon commands. I remembered trying it earlier on a stock rom but it was not available then.
Why I need the swap was because of the frequent shutdown of my launcher pro due to apps contenting for memory. The live wallpaper and heavy Widgets like pure messenger pro aren't helping much either, after much usage the device just slows down, lags and silently kills the background apps. The "minfree" settings were also tweaked but with much less desirable results was seen...
So I downloaded an app called "swapper2" from market and tested via 2 methods; Swap file and swap partition.
The performance of a swap file that sits in the NAND is not really that great. In fact it kinda lags me when memory is being swapped in and out of it. I think its the same problem with the i/o lag problems with any other rom
Then I tried a swap partition on my class 6 SD card. Although the lifespan of the card would be shortened and the battery life would be impacted, the performance is better compared to the earlier method.
In either method, the amont of apps that can be left opened at the foreground and background had increased and doesn't lag as more apps is being launched. Not bad for me but well, I guess it's all up to the user of the device at the end. Just my 2 cents...
I'll try the swap file method again over at the ext2 partition created by the lagfix and see how it goes next. Not sure if anyone interested though...
Sent from my GT-I9000 using XDA App
It seems that using the swap partition doesn't have the lag compared to using the swap file method.
It may be due to the I/O of multiple storage (parallelism ?) is better than a single storage or writing into the raw partition is better in terms of performance than a swap file.
I'm done with my findings, the device still have 60mb free and never lags, I'm sold.
Sent from my GT-I9000 using XDA App
hi guys,Does Quasar kernel support swap?and how to enable it?
i tried to enable it but failed
and i'm thinking about there's a lot of free space that i never used in /data and /system,so why don't we use those useless space to swap for more ram?
or we can use ZRAM?and how to use it?
we have 512 mb memory, for what you want swap?
actually the ram we can use only have less than 300mb
hmm partitionning SDC should do the job, isn't it ? do "ext" partitions have something to do with that ?
I think there's no reason to use swap, but dxdiag32's idea is not bad... internal memory is quicker than sd...
Regards.
Nah, it doesn't support it.
I did some tests with ZRAM and ZCache back in the LG P500 days and it didn't seem to help with anything so I usually disable Swap support now.
Anyway, you can always mount a tmpfs partition to some applications to boost their I/O operations if that's what you're looking for.
Huexxx said:
I think there's no reason to use swap, but dxdiag32's idea is not bad... internal memory is quicker than sd...
Click to expand...
Click to collapse
Depends on the microSD card's class. A class 10 is faster than internal memory.
In fact, it's a shame they dropped the yaffs2 filesystem as in non-sequential I/O operations it's the best one.
Class10 is faster? At least internal memory will be less energy hungry... won't be?
Huexxx said:
Class10 is faster? At least internal memory will be less energy hungry... won't be?
Click to expand...
Click to collapse
Yes, class 10 (>= 10 mb/s write speed) is faster than internal memory.
This is why moving app, data and dalvik to microSD when you have such microSD provides a good boost on I/O operations. There's many folks using the combo CM + S2E + MicroSD Class 10.
As for battery, it's a good question but I bet it should be the same. I/O stuff isn't heavy.
most of us now is using C4 sdcard,at least in China is .so i wanna give us some more performance.my free space in /data partition keep more than 800MB for a long time,and i think more ram can provide us more stable phone.
Beware that RAM works differently for Android devices.
Whereas free RAM in Windows is arguably better than occupied RAM, this is not so for Android. In Android, having RAM allocated is good which is also behind the reason of why we shouldn't use task killers. That being said, we don't really need more than 512 MB of RAM for a heapsize of 32 MB and proper OOM groupings and adj values! Even with an aggressive usage, it's unlikely you'll manage to trigger an OOM (out of memory) throughout your day.
Here's an oldie but goldie article regarding this:
http://lifehacker.com/5650894/andro...ed-what-they-do-and-why-you-shouldnt-use-them
ok got it , thanks knzo
knzo said:
we shouldn't use task killers.
Click to expand...
Click to collapse
I understand the theory but because of my own experience I do not agree in 100% with You. My previous smartphone was Samsung Spica ( not much RAM ). I used to use my favourite IGO for navigation. It was impossible to succesfully launch IGO if I have not used task killer before.
Without task killer IGO just started and vanished within seconds.
pabgar said:
I understand the theory but because of my own experience I do not agree in 100% with You. My previous smartphone was Samsung Spica ( not much RAM ). I used to use my favourite IGO for navigation. It was impossible to succesfully launch IGO if I have not used task killer before.
Without task killer IGO just started and vanished within seconds.
Click to expand...
Click to collapse
That's because IGO triggered an OOM event and the ROM you had instead of doing an intelligent swipe and killing applications based on certain heuristics, was killing the process responsible for the OOM instead (IGO). It's a flag in sysctl called: OOM kill allocating task.
So in that case, it was just a lousy ROM/kernel. Or perhaps in Spica (old kernel, old android version) there wasn't this setting and the phone always killed the application that made the phone run out of memory. This explains why it vanished after a bit.
Either way I stand correct, there's no need for task killers in a device with >= 256 MB of RAM or properly configured.
knzo said:
That's because IGO triggered an OOM event and the ROM you had instead of doing an intelligent swipe and killing applications based on certain heuristics, was killing the process responsible for the OOM instead (IGO). It's a flag in sysctl called: OOM kill allocating task.
So in that case, it was just a lousy ROM/kernel. Or perhaps in Spica (old kernel, old android version) there wasn't this setting and the phone always killed the application that made the phone run out of memory. This explains why it vanished after a bit.
Either way I stand correct, there's no need for task killers in a device with >= 256 MB of RAM or properly configured.
Click to expand...
Click to collapse
Agreed. I still have my old Galaxy Apollo, with 256 MB ram it goes perfectly as it should. In fact, on a careful observation i 've noticed that if we use taskkiller at autokill level at let's say 30 minutes autokill, it will technicall consume 4 CPU cycles in an hour for each app (two for killing, and two when applications like gmail/facebook etc. starts automatically again).. but without taskkiller they may have stay idle, and not used any CPU cycle at all for as many hours as phone is idle. And for battery purpose, it is the CPU cycle that drain, not the used memory !
in my opinion,we only need to kill the apps that use internet in background to save battery.such as Google Maps,once i used it,its services stay in background and after 3 hours i didn't use phone do anything,battery drain 3%,and if i kill it,no battery drain after all
Google Maps and DRM service process sometimes cause battery drains indeed.
knzo said:
Google Maps and DRM service process sometimes cause battery drains indeed.
Click to expand...
Click to collapse
i deleted DRM service,and seems it's no harm to system
Lol but do you know what is it function ?
Sent from my LG-P970 using xda premium
I've seen drm using a lot of CPU as well from time to time. What is it used for and how would you go about removing it?
dxdiag32 said:
i deleted DRM service,and seems it's no harm to system
Click to expand...
Click to collapse
Sent from my LG-P970 using XDA App
masterthor said:
I've seen drm using a lot of CPU as well from time to time. What is it used for and how would you go about removing it?
Sent from my LG-P970 using XDA App
Click to expand...
Click to collapse
You can use Titanium https://market.android.com/details?id=com.keramidas.TitaniumBackup
-Go to Backup/Restore tab
-Find by DRM Protected Content Storage
-Click and select Freeze
Now the app is Freeze and the system don't see more!
Hi!
I have a question about swap and swapper 2. Under advanced tab in swapper 2 there are two options: "recreate swap file" and "reformat swap". Is there any benefit in keeping these two options on? Don't they make enabling swap take longer and additionally decrease SD card life (since the file is constantly being removed and recreated)?
Sorry if it's already been mentioned somewhere but I couldn't find a satisfying answer. I only found some posts telling to tick these two options but without telling why they should be ticked.
Well? Does anyone know the answer?
For the sd life, You just answered your very own question
and for the "recreate swap file" and "reformat swap" options, it brings no differences at all. Because when the phone reboot, it contain previous swap memory intact, but when you open an application (use the swap) it will automatically cleared with an unnoticable delay. While the option "recreate swap file" and "reformat swap" will increase booting time
i used kernel embedded swap, so doesn't very sure
What about swappiness? I currently have 256mb of swap and I tried both 10 and 100 swappiness. From what I've read 100 is supposed to result in some major system performance hit but I didn't notice anything bad happening. Would setting it to 10 mean that the phone will eventually run out of RAM and force close foreground app (like it often happens without swap)?
When we consider only the foreground active app (e.g. a RAM demanding game) is it better to have 10 or 100 swappiness? Also how much swap is too much and why?
CuriousJack said:
What about swappiness? I currently have 256mb of swap and I tried both 10 and 100 swappiness. From what I've read 100 is supposed to result in some major system performance hit but I didn't notice anything bad happening. Would setting it to 10 mean that the phone will eventually run out of RAM and force close foreground app (like it often happens without swap)?
When we consider only the foreground active app (e.g. a RAM demanding game) is it better to have 10 or 100 swappiness? Also how much swap is too much and why?
Click to expand...
Click to collapse
well, swappiness value alter the system which memory to use the most,
e.g. 0 will use ram until it full then slowly fill the swap, otherwise 100 inverted result.
it is recommended to set swap between 30-90, as the ram have lesser latency and for normal usage(i can play angry grand with 49 swappiness, starting lag abit then it smoothed).
for heavy gamer, you will need set from 60 to 100 as you needed.
and for swap capacity, the more the good . if your swap are more enough, android tend to keep most of the application you used the most keep in memory so, the next time you open that app, it will be fast
and for need of swap capacity more than 256mb, you'll need use partition wizard to make it
which is the better option for performance (with respect to speed and multitasking)
As I understand it zRam compresses unused apps within the system RAM. So there is a CPU cost as well as reduced available RAM for other apps.
Swap files don't restrict available RAM but writing to the sdcard impacts the speed of opening apps.
Can both be used at the same time? I don't think so, but maybe I'm wrong. And perhaps using both has a negative impact on performance.
If only one is a viable option, which one should I use?
for me swap is better