[Q]What is VM heap size and how it works!? - Android Software/Hacking General [Developers Only]

I've been seeing This CM7 and wanted to know what this was?!
I'm always reading how people say that xxMB is the best size.
But what is it? And how it works?
What's it for? What's the right size for a Galaxy S?

VeryCoolAlan said:
I've been seeing This CM7 and wanted to know what this was?!
I'm always reading how people say that xxMB is the best size.
But what is it? And how it works?
What's it for? What's the right size for a Galaxy S?
Click to expand...
Click to collapse
This setting is simply the maximum amount of heap space (read: memory) a single instance of the Dalvik VM (read: application) can obtain.
Don't read anything into the "benchmarks" performed. This setting should have little effect on overall system performance. The only scenario where it would be beneficial to increase the maximum heap size would be if you have an application that is very close to using up all of its available heap space, which would force it to run garbage collection frequently, which would use up CPU cycles. It is possible that lowering the maximum heap size could be beneficial in that it might prevent an application from obtaining more memory than it needs (by forcing it to garbage collect sooner), but that all depends on how the Dalvik VM is implemented and is really beyond my knowledge.

The heap (in Java) stores dynamically allocated variables, such as objects. Like Rueben_ said, when the heap is running low on memory, the JVM will run garbage collection. Garbage collection uses processing cycles, which will slow down your phone. In case you're wondering, the other place in memory where things are stored is called the stack, which stores arguments and parameters.

Oh okay
So how do you how much memory to put it for at Max?
Sent from my SGH-T959 using xda premium

mrinehart93 said:
In case you're wondering, the other place in memory where things are stored is called the stack, which stores arguments and parameters.
Click to expand...
Click to collapse
I do believe the stack is reserved for storage of CPU data (typically, the contents of its registers) before it switches toanother context (or thread, which means loading a different set of data in its registers).
The memory zone where data from user apps (and the Dalvik VM is one of those, albeit a über-app of sorts since it runs all the other apps) is stored is rather just called "the heap". At least that's the way I learned it

daxdax89 said:
So is it better to put higher or lower heap size for games?
Click to expand...
Click to collapse
There is no right answer for this as you should have gathered from reading the answers you were given.
It all depends on how you use your phone.
Try out different settings with games and you'll see which suits your usage best.
Go on - Live on the edge a little lol...

daxdax89 said:
So is it better to put higher or lower heap size for games?
Click to expand...
Click to collapse
For the Vibrant if you use big apps then put the VM at like 128 or or something like that.
If you have small flashlight apps then use it at 32-96
Sent from my SAMSUNG-SGH-I747 using xda premium

Say, this seems to be a "magic bullet" for devices with modest memory sizes to keep apps from swamping the available memory. For my 1 GB Lollipop device, setting dalvik.vm.heapsize to "96m" improved the performance of the device. I was able to cycle between many memory-heavy applications without getting bogged down.
Be careful! Forgetting the "m" at the end, or setting the number too low will send your device into an endless garbage-collection, essentially locking you out. I set it too low myself, had to pop the battery, then quickly raise the value after reboot (before the "system_server" app got itself above the limit I had set), rebooting again to apply the new value. For a fair indication of a lower limit, look at the memory consumption of the "system_server" app. Set it above that to give it some headroom. Make sure you have a recovery plan before messing with this value!

Related

[IDEA] Smart Swapper

I was thinking the other day about people opinions about using swaps and what the swappiness should be set to. I thought about how at sometimes during heavy use a higher swappiness would help while at other times it could slow things down. I was wondering if it would be possible to make a "smart" Swapper app that ran in the background and automatically adjusted the swappiness according to how much free memory is needed. For example when the phone is idle in your pocket swappiness would be at 10 but then as your started to browse the web or use GPS it would increase swappiness to allow you to have more free memory. Feel free to tell me why this is not practical or possible, it was just a thought I had.
I don't this its a case of being impossible
the question is why?
if your phone is 'sleeping' it probably isn't doing much with swap, so reducing swappiness won't achieve anything.
increasing swappiness when your phone comes to some load threshold will only increase the 'load' on swap as all of a sudden you want to dump more stuff from real memory into swap
tbh I don't understand why so many are obsessed with swap.
my advice , keep swappiness at default, and as for size of swap, large
why large?
good question, as you never really fill more than 40mb..
the reason for 'large' is 'wear levelling' your swap takes a hammering, if this partition is large then each block is going to have less writes on it than a smaller swap partition over a given period of time, thus increasing the life span of your sd card.
Agreed, playing with swappiness doesn't really help a whole lot.
One of the bigger issues (imo) is how once you have swap turned on the kernel will swap inactive pages out in order to make room for IO caching. If your device is sleeping, a lot of pages are suddenly inactive.
While at first it might seem like you'd want the ram to make up for a slow SD card, swapping out to the same device in order to make room for cache is counterintuitive. Unfortunately there is no way to cap the total amount of ram that can be used for cache. The logic is that unused ram and inactive pages can be put to better use to speed up IO.....except on devices with extremely limited ram and IO like most smartphones.
It's pretty unlikely that anything like that will make it back into the linux kernel any time soon. :\
Then again you never know Lunix is open sourced as well as android anything is possible
The idea is correct, but as said, it isn't possible. Don't count on any linux changes in the future on this. On the other hand, i think there is a possibility, but this should be calculated.
Swapiness is set on boot, right? If i change it when running my phone, would this make any difference on further use?
Now my suggestion is, find out what swapiness is ideal. When the program can calculate the ideal swapiness level, based on how much RAM is used over time, this would be nice? It would write this level down in a userinit, and when you reboot the phone, it would use this level as a reference point on swapiness.
Only downside is that you can't figure out the ideal swapiness, it depends on the phone, apps and personal preference.
Anyone has comments on this idea?

[CompCache] Setting compcache to full RAM size

I've always run compcache on my ROMs when possible and I recently had the idea that setting the full amount of RAM to compcache could be an interesting test. The theory being that it may be slightly slower overall to have ramzswap compressing pages, but minfree would have heaps of memory to play with and apps would never quit, so multitasking would be faster as no apps are writing out to /data and then having to relaunch when I switch to them again.
I've set compcache with the init script like so
Code:
insmod /system/lib/compcache/ramzswap.ko;
rzscontrol /dev/block/ramzswap0 -i -d 98304;
busybox swapon /dev/block/ramzswap0;
And Linux reports the swap is working
Code:
# free
total used free shared buffers
Mem: 107332 105972 1360 0 8
Swap: 98296 48940 49356
Total: 205628 154912 50716
But no matter what I do, even if I launch a heap of apps, I can never get swap usage above the ~48Mb RAM seen here.
Furthermore, apps like Auto Killer and Free Memory only report I have 102Mb RAM total.
What's going on here? Why does Android think it only has 100Mb when free is reporting near on 200Mb total? Why does compcache only fill up halfway and no more? Does this mean that ~48Mb RAM is the "sweet spot" for compcache and any more is pointless?
The phone does feel faster when switching between apps but I could just be imagining it. Out of interest this is a 32B Magic running Dwang 1.17.1, which is basically just Donut AOSP with a faster framework and kernel.
Any ideas/help/suggestions would be appreciated?
Swap is never, ever, regarded by the system as real memory, hence why the system won't report it, since you really only have ~100 mb physical ram.
As to why you're only using 48, I believe that 48 is 1/2 96, so it probably means pages are being compressed 2:1, so the full memory is being compressed and dumped into RAM, and it only occupies 48 MB, leaving you 48 free for other processes.
Again, remember comcapche is swap, not real memory.
jubeh said:
Swap is never, ever, regarded by the system as real memory, hence why the system won't report it, since you really only have ~100 mb physical ram.
As to why you're only using 48, I believe that 48 is 1/2 96, so it probably means pages are being compressed 2:1, so the full memory is being compressed and dumped into RAM, and it only occupies 48 MB, leaving you 48 free for other processes.
Again, remember comcapche is swap, not real memory.
Click to expand...
Click to collapse
I don't think that that analysis is quite right....
First off, you MUST maintain SOME amount of real memory available... otherwise it'll crash in a spectacular way. I believe that the linux kernel itself may have a safety feature that maintains a certain minimum amount of physical ram available. There ARE certain things that the linux kernel will not be willing to swap, such as ITSELF.
Just imagine what would happen if the kernel swapped itself..... any attempt to do this wouldn't end well. Especially if it tried to swap its ENTIRE self since the kernel MUST be in memory in order for it to run.
There is also the swappiness setting... it controls the system's tendency to swap.
And finally, there is the possibility that you may simply not be starting enough processes to consume the full memory!
So imagine this; you have your compcache set for a certain size. It grows to that size and then finally, the kernel says "screw you, you can't have any more memory!" blows an error back to compcache, which complains back to the kernel "sorry, swap is screwed." Yep.... the kernel tells compcache which tells the kernel rather than the kernel just knowing.
You definitely don't want this happening.
Note: I can forsee some serious stability problems that this could result in related to the low memory process killer. Specifically, your compcache grows to its maximum allowed size, you start an application, the low memory process killer figures that you've got plenty of memory available, doesn't kill anything off, tries to start some application, crashes spectacularly when the kernel complains back that it doesn't have any memory. I don't know if this would happen with a stock low memory process killer, but definitely would with the swap hacks added....
lbcoder said:
Note: I can forsee some serious stability problems that this could result in related to the low memory process killer. Specifically, your compcache grows to its maximum allowed size, you start an application, the low memory process killer figures that you've got plenty of memory available, doesn't kill anything off, tries to start some application, crashes spectacularly when the kernel complains back that it doesn't have any memory. I don't know if this would happen with a stock low memory process killer, but definitely would with the swap hacks added....
Click to expand...
Click to collapse
92 MB of compcache doesn't really need 92MB of compcache... that's the point of being compcache.
Compcache file in RAM grows when cache gets stuffed inside compcache.
Setting a low swappiness will cause compcache to just swap what's needed.
And even with full compcache, in the end you end up having around 140 mb (or so) free ram. 92mb of compcache that takes like 50mb and 42 extra mb of normal ram.
I think this idea is great (I was just too lazy to try yet...). Instead of dalvik vm having to free up memory it can stuff some more mb in compcache. should be faster.
I didn't really think my post through... but I hope some of you understood some of the things I wanted to communicate xD
domenukk said:
92 MB of compcache doesn't really need 92MB of compcache... that's the point of being compcache.
Compcache file in RAM grows when cache gets stuffed inside compcache.
Setting a low swappiness will cause compcache to just swap what's needed.
And even with full compcache, in the end you end up having around 140 mb (or so) free ram. 92mb of compcache that takes like 50mb and 42 extra mb of normal ram.
I think this idea is great (I was just too lazy to try yet...). Instead of dalvik vm having to free up memory it can stuff some more mb in compcache. should be faster.
I didn't really think my post through... but I hope some of you understood some of the things I wanted to communicate xD
Click to expand...
Click to collapse
Interesting in theory, but if you actually read what I said, you would note that this is entirely IMPOSSIBLE and would crash spectacularly if not for and in some cases in SPITE of certain safety features built into the kernel.
Note: If you have 70 MB worth of data that CAN'T be swapped, that leaves 20 MB ***PEAK*** available to compcache.
It is neither fair nor sensible to think of all memory as being equal. Running processes ***MUST*** have REAL MEMORY.
A little off-topic, but this discussion (the possibility of REAL "compressed" memory) sparked a thought/question:
Would/could KSM* bring any benefit to Android? (Not sure if the KSM module can even compile/work on ARM)
I know KSM is normally used for detecting and sharing duplicate pages among KVM guests, but I wonder how many pages in a typical running Android installation are duplicated, and thus candidates for sharing/de-duplication.
*I can't posts links yet, so those that don't know what KSM is, will just have to google for it.
lbcoder said:
There ARE certain things that the linux kernel will not be willing to swap, such as ITSELF.
Click to expand...
Click to collapse
I was under the impression the kernel keeps itself in RAM and then reports free memory to the rest of the OS. This is why the phone physically has 192Mb RAM, but only reports 96Mb free (or 107Mb with RAM hack). Perhaps my understanding of Linux/Android memory reporting is not correct?
lbcoder said:
It is neither fair nor sensible to think of all memory as being equal. Running processes ***MUST*** have REAL MEMORY.
Click to expand...
Click to collapse
I think this is likely what is happening. Home, Phone, System and other processes with a low oom are refusing to swap out as they are still running. If the compcache allocation in RAM is dynamic as domenukk says, then those processes are occupying enough RAM that the ramzswap allocation can only grow to ~48Mb as I am seeing. I didn't think of this.
Nor have I tweaked swappiness. It's currently set to 60 (default) so I'd assume it's not too fussy with paging out. I will try playing with this at 10 and 100 to see if I can force anything more into swap or if it's less willing to swap.
brainbone said:
*I can't posts links yet, so those that don't know what KSM is, will just have to google for it.
Click to expand...
Click to collapse
I do not know either, but here are some links people may wish to look at
http://fedoraproject.org/wiki/Features/KSM
http://lwn.net/Articles/306704/
http://lwn.net/Articles/330589/
http://www.linux-kvm.com/content/using-ksm-kernel-samepage-merging-kvm
Ok I am not at all experienced in this area but this is just a suggestion. You say that you can only get 48mb of swap to be compressed at a time. If those 48mb were uncompressed, then that would occupy the 98mb you alloted to it. If you set the cc at say 128mb, then in (my) theory up to 64mb of it the actual ram would be used. I don't know how much sense I'm making but not sure exactly how to explain it. If you don't get it I'll try explaining my logic a little more in depth.
mejorguille said:
If you set the cc at say 128mb, then in (my) theory up to 64mb of it the actual ram would be used.
Click to expand...
Click to collapse
It appears you are right. Even with swappiness set to 100 and opening every app on my phone I'm not able to fill more than half of 128Mb compcache before minfree stats gracefully closing processes:
Code:
/opt/android-sdk-linux_86/tools$ ./adb shell free
total used free shared buffers
Mem: 107332 105956 1376 0 32
Swap: 131064 65520 65544
Total: 238396 171476 66920
Super Jamie said:
It appears you are right. Even with swappiness set to 100 and opening every app on my phone I'm not able to fill more than half of 128Mb compcache before minfree stats gracefully closing processes:
Code:
/opt/android-sdk-linux_86/tools$ ./adb shell free
total used free shared buffers
Mem: 107332 105956 1376 0 32
Swap: 131064 65520 65544
Total: 238396 171476 66920
Click to expand...
Click to collapse
I rock=p
So what's your performance like, compared to say 32mb cc or no cc at all?
It's different but I like it.
There is sometimes a slight (<2 second) pause when launching a new app (I assume this is compcache compressing old pages to swap to make way for the new app) however once the app is up and running, it almost never "exits" so switching between previously-launched apps is noticeably faster than without compcache. I run HelixLauncher Donut and it's never closed and re-launched while I've been trying this, however it did sometimes with 32Mb cc and quite often without cc at all.
I had 5 day uptime last week with 96Mb compcache (rebooted whilst testing another app for a friend) so I don't think stability is an issue. The CM wiki indicates performance with cc is better upon boot then gradually declines, even if that is the case, rebooting my phone once a week is no big issue.
Unless I run into any major issues, I'll be keeping my phone with large compcache
Super Jamie said:
I was under the impression the kernel keeps itself in RAM and then reports free memory to the rest of the OS. This is why the phone physically has 192Mb RAM, but only reports 96Mb free (or 107Mb with RAM hack). Perhaps my understanding of Linux/Android memory reporting is not correct?
I think this is likely what is happening. Home, Phone, System and other processes with a low oom are refusing to swap out as they are still running. If the compcache allocation in RAM is dynamic as domenukk says, then those processes are occupying enough RAM that the ramzswap allocation can only grow to ~48Mb as I am seeing. I didn't think of this.
Nor have I tweaked swappiness. It's currently set to 60 (default) so I'd assume it's not too fussy with paging out. I will try playing with this at 10 and 100 to see if I can force anything more into swap or if it's less willing to swap.
I do not know either, but here are some links people may wish to look at
http://fedoraproject.org/wiki/Features/KSM
http://lwn.net/Articles/306704/
http://lwn.net/Articles/330589/
http://www.linux-kvm.com/content/using-ksm-kernel-samepage-merging-kvm
Click to expand...
Click to collapse
ksm sound cool. As every app runs inside dalvik vm. Not sure though... somebody should ask cyanogen
I am happy thatlarge compcache works out so well for you.
BTW doesn't cyanogenmod 5 count the whole swap as real memory since test4 or so?
Oh and overclocking ondemand to as high as possible will speed up app opening and switching a lot while on compcache
domenukk said:
doesn't cyanogenmod 5 count the whole swap as real memory since test4 or so?
Click to expand...
Click to collapse
It's counted as available "swap" memory, but not "real" ram. Pages stored in "real" ram (memory that the cpu can directly execute code in) still need to be freed up (moved to swap) before previously swapped pages can be moved back in to "real" memory to be executed.
domenukk said:
ksm sound cool.
Click to expand...
Click to collapse
The beauty of KSM is that it does no "swapping". It simply combines 4KB pages that are identical -- so instead of two identical 4KB pages using 8KB of ram, they only take 4KB. The code is executed in place.
KSM would, however, still require swap. If at any time a virtual shared 4KB page is written to, it needs to be copied to a free page to avoid corrupting the virtual page it was a duplicate of before the write. Swap is needed to ensure that there will always be enough available free pages when this happens.
domenukk said:
As every app runs inside dalvik vm.
Click to expand...
Click to collapse
KSM is not dependent on a VM, but the existence of VMs (java or otherwise) increases the likelihood of duplicate pages.
domenukk said:
Not sure though... somebody should ask cyanogen
Click to expand...
Click to collapse
I'd certainly be interested in cyanogen's thoughts on this, but I'm sure there are others that would be able to chime in as well.
Relevant excerpt from kernel.org/doc/ols/2009/ols2009-pages-19-28.pdf
KSM and embedded
KSM is suitable to be run on embedded systems too; the important thing is not to register in KSM regions that won’t likely have equal pages. For each virtual page scanned, KSM has to allocate some rmap_item and tree_item, so while these allocations are fairly small, they can be noticeable if lots of virtual areas are scanned for no good.
Furthermore, these KSM internal rmap/tree data structures are not allocated in high memory. To avoid early out of memory conditions, it is especially important to limit the amount of lowmem allocated on highmem 32bit systems that might have more than 4GB of memory, but these shouldn’t fit in the embedded category in the first place.
Click to expand...
Click to collapse
Super Jamie said:
I was under the impression the kernel keeps itself in RAM and then reports free memory to the rest of the OS. This is why the phone physically has 192Mb RAM, but only reports 96Mb free (or 107Mb with RAM hack). Perhaps my understanding of Linux/Android memory reporting is not correct?
Click to expand...
Click to collapse
Memory reporting is a tricky thing.
But in general, when RAM is allocated to HARDWARE, it is NOT REPORTED.
The chunk of the 192 that is not reported is assigned PRIMARILY to the RADIO. Another chunk is assigned to the GPU. Still more is assigned to the AUDIO HARDWARE.
The part used by the kernel itself IS reported. The most trivial empirical evidence to prove this to you is that when you change KERNELS, it doesn't affect the total system memory, despite your KNOWING that different kernels use different amounts of RAM.
Another bit of empirical proof is that activating COMPCACHE does not reduce the total physical ram reported. And yes, COMPCACHE is part of the kernel...
Now here's another concept of crash and burn: IF everything in memory could be cached in compcache, then what would stop compcache from caching compcache in a horrible infinite memory sucking loop? That would be very very bad, LOL.
I think this is likely what is happening. Home, Phone, System and other processes with a low oom are refusing to swap out as they are still running. If the compcache allocation in RAM is dynamic as domenukk says, then those processes are occupying enough RAM that the ramzswap allocation can only grow to ~48Mb as I am seeing. I didn't think of this.
Click to expand...
Click to collapse
NOW you're getting the idea! Running processes, kernel, etc., all need physical RAM (though actually those processes you mention most definitely CAN be swapped...), and therefore you CAN'T make the ENTIRE RAM into compcache!
Nor have I tweaked swappiness. It's currently set to 60 (default) so I'd assume it's not too fussy with paging out. I will try playing with this at 10 and 100 to see if I can force anything more into swap or if it's less willing to swap.
Click to expand...
Click to collapse
Just beware of possible crash-and-burn
Super Jamie said:
It appears you are right. Even with swappiness set to 100 and opening every app on my phone I'm not able to fill more than half of 128Mb compcache before minfree stats gracefully closing processes:
Code:
/opt/android-sdk-linux_86/tools$ ./adb shell free
total used free shared buffers
Mem: 107332 105956 1376 0 32
Swap: 131064 65520 65544
Total: 238396 171476 66920
Click to expand...
Click to collapse
That doesn't actually follow from what you've posted here.
What follows is that 105956-(65520/2)=73196 of what occupies your memory can't be swapped (kernel, running processes, etc.).
lbcoder said:
What follows is that 105956-(65520/2)=73196 of what occupies your memory can't be swapped (kernel, running processes, etc.).
Click to expand...
Click to collapse
Do you know why swap constantly "settles" at almost exactly half usage regardless of what size compcache I set?
For example, I set 64Mb compcache yesterday and rebooted. Just using my phone normally (browser, genie widget, music) I have this:
Code:
total used free shared buffers
Swap: 63992 32096 31896
Does this mean I am effectively reducing the amount of RAM the phone has for the kernel, "foreground app", "visible app" and "secondary servers" (to use the minfree terms), whilst at the same time allowing more "hidden app" and lower processes to swap out instead of terminating gracefully?
This disturbs me
-------------------------------------
Sent via the XDA Tapatalk App
brainbone said:
I'd certainly be interested in cyanogen's thoughts on this, but I'm sure there are others that would be able to chime in as well.
Click to expand...
Click to collapse
He doesn't know much about it, yet. But he seems inerested.
Attached a short conversation over #twitter
# Dominik domenuk
@cyanogen Is ksm any good 2 save RAM? probably not - you would have already done it http://lwn.net/Articles/329123/
# Steve Kondik cyanogen
@domenuk I don't know too much about it, I think its meant for sharing between distinct virtual machines
@domenuk it could have a lot of potential though
# Dominik domenuk
@cyanogen basically yes. But he states its also for normal apps. I have no idea to what extend android apps have similar memory, though...
# Steve Kondik cyanogen
@domenuk a lot, Android is all about IPC and shared memory. I wouldn't be surprised if the Dalvik people are thinking about it.
Click to expand...
Click to collapse
Here is a way to make Android use more than 50 percent of a swap partition. I am not sure how it will act with compcache... Should be the same... Run the following commands from a terminal or add them following to your userinit.sh file:
Code:
su
echo 80 > /proc/sys/vm/swappiness
echo 150 > /proc/sys/vm/vfs_cache_pressure
!!WARNING!! - Messing with VM settings can cause data loss and system instability... Not liable for damages...
Using the above the "free" output is:
Code:
total used free shared buffers
Mem: 97708 95168 2540 0 356
Swap: 125296 88756 36540
Total: 223004 183924 39080
While we are at it... If anyone is willing... they can try this as well:
echo 1 > /proc/sys/vm/oom_kill_allocating_task
Reference : Article to Linux Insight
Been having pretty good results with it...
Here is a link to the rest of the vm settings...
Linux Insight article listing vm settings
L8r

[Q] Making Swapfile on Gtab 7+?

hi guys,..
i want to ask is there any way i can make swapfile on gtab 7+ running hc 3.2? or there is no posibility to make swapfile on honeycomb? i've tried to make the swapfile using dd command from terjinal, but somehow im stucked on setting permission for the file, the file i've created always have special permission that i can't change to rw-r-r, it always stayed rw-rSw-r, im a newbie on linux things, and willing to learn.
any help really appreciate.
thanks.
Okay, you say that you're a newbie to linux. That's fair and reasonable. I'm going to try and teach you some things by way of asking questions. They might sound like I'm attacking you, but I'm not...
Do you know you are trying to create a swap file? What do you hope to gain by doing so?
Is this one of those mythical magical things that someone claims will make the tablet run 50395920 times faster, allow it to brew coffee, and make your car get better fuel mileage?
...and some answers...
Within the android environment, a swap file is a BAD THING. The entire system is designed to drop stuff out of memory if/when it needs more memory, and the overhead of a swapfile will cause more harm than good.
Take care
Gary
garyd9 said:
Within the android environment, a swap file is a BAD THING. The entire system is designed to drop stuff out of memory if/when it needs more memory, and the overhead of a swapfile will cause more harm than good.
Click to expand...
Click to collapse
It's not that dramatic. Most of "the overhead of a swapfile" is overhead you're already committing to by utilizing a VMM (Virtual Memory Manager). The Dalvik VM doesn't do a whole lot of its own memory management so implementing a swapfile at the OS level, which is what the OP is looking to do, wouldn't have a huge impact on performance.
The only time where you'd have any real overhead of maintaining a swapfile is when memory is full and the OS pages out memory to disk. But remember that the alternative is to close down the process and run some garbage collection. Both are intensive actions - swapfile is I/O intensive while GC is CPU and memory intensive - so you're really trading one source of overhead for another.
To answer the OP's question, it sounds like you haven't rooted the tab. You would need to be root in order to change the perms as you described. If you are rooted, make sure you're using the right command to set permissions - I haven't tried this specifically on Android but from my *nix experience, the command you want is chmod 644 <path to file>
---------- Post added at 09:24 PM ---------- Previous post was at 08:39 PM ----------
Almost forgot, what kernel are you using?
im using stock kernel 2.6.36, kk6 rooted. i've tried to chmod the swapfile, but still cant change the permission, i usually use root explorer to change the permission, but now it doesn't take effect. the file permission r8 now is rw-rwSr--, the "S" thing is making the swap cant be aplied (i guess).
back there when i use optimus (gingerbread), swapfile is default from stock rom. is it have something to do with honeycomb?
thanks for your reply.
garyd9 said:
Okay, you say that you're a newbie to linux. That's fair and reasonable. I'm going to try and teach you some things by way of asking questions. They might sound like I'm attacking you, but I'm not...
Do you know you are trying to create a swap file? What do you hope to gain by doing so?
Is this one of those mythical magical things that someone claims will make the tablet run 50395920 times faster, allow it to brew coffee, and make your car get better fuel mileage?
...and some answers...
Within the android environment, a swap file is a BAD THING. The entire system is designed to drop stuff out of memory if/when it needs more memory, and the overhead of a swapfile will cause more harm than good.
Take care
Gary
Click to expand...
Click to collapse
thanks m8 for your lighten up of linux, i really appreciate it. just from my experient when im using optimus (gingerbread) i never felt lack of memory when using multitasking (it only has 512mb ram). but now when i using gtab (with 1gb ram or 778mb?) first it fast on multitasking but about 10 minute later it getting slower, when i check with task manager, it only has 80mb left??
is it me or is it gingerbread have better ram management than honeycomb, and so if it is, im trying to make swapfile in hope that its getting better. i use v6 supercharger, kill all proccess when it turn to standby by automatic, overclocking to 1,6ghz, but still i can make the ram more efficient when running on multitasking.
hope you understand for what im going to achieve.
thanks.
h2g2 said:
It's not that dramatic.
Click to expand...
Click to collapse
Are you suggesting that using an OS-level "generic" swapfile on flash memory is better or even equivalent to using a system/purpose built solution?
The linux kernel has no way to know if the memory its swapping out is even needed anymore. The android system, however, does know this - and will often discard allocations.
Let's say you run two applications: email and the browser. The browser has several pages loaded with flash, and lots of memory intensive stuff going on. Also in memory is the code that syncs your email in the background and several other "non critical" services (such as SMS, latitude, etc.) and a few critical services (such as some wifi support, display support, framework, etc.)
Keep in mind that if android requests memory, and there's a swapfile, the kernel will claim it has memory backed by swap... So given a large enough swapfile, the kernel will never tell android that it's running short on memory...
Given the above situation, the user now wants to run Angry Birds. There isn't enough physical RAM to support all of the above in memory AND Angry Birds. What will happen?
If there's no swapfile, android will see there isn't enough RAM to support it, and simply drop the browser and email client from memory, but keep the services in memory. Angry birds loads, and the user is happy.
IF there IS a swapfile, however, then android will see that there is RAM to support AB along with everything else in memory, and just load Angry Birds. When that happens, the linux kernel will have to swap pages of memory out to the flash memory. The KERNEL doesn't know the difference between the email client, the email service, the browser, or any other "non-critical" service. All those memory pages are flagged the same. So, perhaps the browser gets swapped out. (wasted cycles - it could have been discarded.) The email client is retained in RAM, but the email service is swapped out to flash. Angry Birds loads. 5 minutes later, Angry Birds freezes and gets jumpy... why? Because the email service has to be swapped back into RAM, and something else swapped out in its place. This time it was latitude. A few minutes later, latitude wants to update your position, so the same thing happens. What gets swapped this time?
Why spend the cycles swapping things in and out of RAM? There is plenty of memory on these devices to support all the services and memory hungry games. If some game has a memory leak, you SHOULD be getting errors from running out of memory and NOT blissfully swapping things to flash.
I'm not going to tell people how to use their devices. I'm going to try and give them advice, but I certainly can't force people to take it. As a matter of fact, I'll even encourage the technical minded to explore and break things to learn on their own.
However, when a person asks the question I see in the OP, and admits that they are new to linux, then I suspect that they aren't technically minded and exploring, but blindly following the "suggestion" of someone else who promises all kinds of silly things. It reminds me of someone who disabled kernel panic reboots and claimed that it was a tweak to make the system more stable... and had many people actually believing that.
There's a good reason why google hasn't enabled swapping, and there's even less of a reason with devices that come with 1GB of RAM.
Take care
Gary
---------- Post added at 01:45 AM ---------- Previous post was at 01:25 AM ----------
danielkaboom said:
is it me or is it gingerbread have better ram management than honeycomb, and so if it is, im trying to make swapfile in hope that its getting better. i use v6 supercharger, kill all proccess when it turn to standby by automatic, overclocking to 1,6ghz, but still i can make the ram more efficient when running on multitasking.
hope you understand for what im going to achieve.
thanks.
Click to expand...
Click to collapse
First of all, try the same thing without that "supercharger" script. I've made clear my thoughts on that. In this case, using that script may or may not be allowing HC to do what its designed to do in regards to memory management. I'm not saying you should delete it - but to run tests without it.
If you are running low on FREE memory, that's not a bad thing. What good is the memory doing if it's not being used? Android will let an unused application linger in RAM as long as they wants so long as nothing else needs that RAM. As soon as something else needs that RAM, those unused apps will be purged (garbage collection.)
Having a swap file directly contradicts any effort to purge things from memory. A swapfile will encourage the system to swap things to flash as virtual memory. Sure, your "free memory" number might be bigger, but it will slow the system down when it's swapping things out to and in from flash memory. (A blunt question Are you chasing numbers or actual performance?
How do you expect to make memory MORE efficient by always having it be unused? Memory that's not being used is wasted. If my desktop machine (that has 16GB of RAM) has only 6GB being used, then I have 10GB of RAM wasted. I'd rather that memory be used to store an application I might go back to using, or used as cache. Completely unused RAM is completely wasted RAM.
I understand that you might be caught up in the whole thing with overclocking, having as much free RAM as possible, and having nice benchmark numbers. The thing is.. NONE OF THAT MATTERS.
Want higher benchmark numbers? I can make you a kernel that will give you insanely high numbers. Your device will suck for actual use, but you'll get high benchmarks.
Want a big "free RAM" number? Never run any apps, never get email, don't do anything at all with the device. It'll be an expensive paperweight, but you'll always have lots of free (and completely wasted) RAM.
Try this: make a backup of your system and then go back to stock. Use your tablet in a factory state for a few days. Then root it and disable some of the things that might be chewing the battery. Don't overclock, don't install scripts, and don't install a custom kernel. Use the device like that for a while. Actually USE the device - don't benchmark it, check task managers, etc. Just use it.
Now, how does it feel? No script, kernel, or anything else will make a dramatic performance increase. They can (and often do) make things slower, however. (That's why I'm very careful about modifications I make to my kernel...)
After using it stock for a few days, come back and tell us what you think - what you wish would be better in actual day to day use. (Again, benchmarks and numbers don't mean much...)
Take care
Gary
yes Gary,...to be honest, im blindly follow every1 that claims can tweaks or anything like tha, but when i tested it and using it, if its making my device getting "better" i kept it, if its making it worse than before, i let go.
in my opinion, slow, fast or faster is relative, it depends on every1 needs. for me loading game such as finalstrike hd in 5 sec is fast, but maybe different to others by loading it 20-30 sec is acceptable.
but if you said swapfile is bad and will only making it worse, then i'll accept that, but after im testing it. for me, sugar is not sweet until my tounge said so, no offence.
again, thanks Gary for the explanation, thanks for opening my mind.
edit : ill try to follow your instruction first.
You should do what you feel like, but please don't get caught up in lots of people telling you that they have magic bullets to fix things (that really aren't even broken.)
That being said, you are having a technical problem and I just can't resist information sharing.
What directory are you trying to create the file in? /sdcard (or /mnt/sdcard) won't work.
Try /data
(/mnt/sdcard == /sdcard.. and they will force certain permissions via fuse/vold.) Unlike GB, with HC /data and /mnt/sdcard use the same space. (/mnt/sdcard is actually a fuse from /data/media.) (In GB, /data space was very limited. That's not the case with HC.)
Gary
still failed,...:
- create a file in /data (named swapfile.swp), using terminal
# dd if=/dev/zero of=/data/swapfile.swp bs=1024 count=128000
- check from root explorer, the file is now created.
# mkswap /data/swapfile.swp
# swapon /data/swapfile.swp
swapon /data/swapfile.swp = Function not implemented
any sugestion?
edit : the permission is now can be change to rw-r--r--(thx Gary)..but its still failed to swapon,..
edit 2 : from what i've read from other pages and sites,..is it because "kernel not support"?
garyd9 said:
Are you suggesting that using an OS-level "generic" swapfile on flash memory is better or even equivalent to using a system/purpose built solution?
Click to expand...
Click to collapse
There is no "system/purpose built solution" - the Dalvik VM uses the Linux kernel VMM functions for low level memory management (http://developer.android.com/guide/basics/what-is-android.html).
The linux kernel has no way to know if the memory its swapping out is even needed anymore. The android system, however, does know this - and will often discard allocations.
Click to expand...
Click to collapse
Yes it does. The VMM knows which pages are active, which are inactive, and - if an application has called free() on a pages it previously malloc()'d, it will know which pages are expired.
In fact, the VMM will often know more than the Dalvik VMs because each application runs in its own Dalvik thread with its own dedicated heap. Any individual Dalvik instance will only know the disposition of the heap for its own application.
The VMM, on the other hand, has visibility of all Dalvik threads and will know which threads are idle and which are active, which Dalvik threads have run garbage collection and free()'d a portion of their heap, etc.
Keep in mind that if android requests memory, and there's a swapfile, the kernel will claim it has memory backed by swap... So given a large enough swapfile, the kernel will never tell android that it's running short on memory...
Click to expand...
Click to collapse
No, it won't. That's not how the swapfile works. What you're describing is more akin to memory-mapped file I/O, which is related (in that the VMM plays a role in managing that address space) but not at issue (it's a completely separate operation from memory allocation and de-allocation).
Memory is requested by giving the kernel a malloc() command. The VMM will then check its page cache (the size of which is constrained by physical memory - regardless of whether there is a swapfile or not) and look for available space. If space isn't available, then the VMM will look for pages marked as expired. If there aren't enough expired pages, it will look for inactive pages (pages allocated by processes that are idle or supsended).
At this point, the VMM will either 1) discard the contents of the expired and/or inactive pages until enough free pages are available (if no swapfile is available) or 2), write the contents of the expired and/or inactive pages to the swapfile before discarding them until enough free pages are available.
Note that the presence or absence of the swapfile has no bearing on what pages are chosen. And again, regardless of whether there is a swapfile or not, if there aren't enough expired and/or inactive pages to get rid of, malloc() returns a null pointer. In otherwords, you will get out of memory errors even with a giant swapfile.
Given the above situation, the user now wants to run Angry Birds. There isn't enough physical RAM to support all of the above in memory AND Angry Birds. What will happen?
If there's no swapfile, android will see there isn't enough RAM to support it, and simply drop the browser and email client from memory, but keep the services in memory. Angry birds loads, and the user is happy.
IF there IS a swapfile, however, then android will see that there is RAM to support AB along with everything else in memory, and just load Angry Birds. When that happens, the linux kernel will have to swap pages of memory out to the flash memory. The KERNEL doesn't know the difference between the email client, the email service, the browser, or any other "non-critical" service. All those memory pages are flagged the same. So, perhaps the browser gets swapped out. (wasted cycles - it could have been discarded.) The email client is retained in RAM, but the email service is swapped out to flash. Angry Birds loads. 5 minutes later, Angry Birds freezes and gets jumpy... why? Because the email service has to be swapped back into RAM, and something else swapped out in its place. This time it was latitude. A few minutes later, latitude wants to update your position, so the same thing happens. What gets swapped this time?
Click to expand...
Click to collapse
So bearing in mind that the Linux kernel VMM is ultimately responsible for choosing what gets dropped or swapped out of memory and also bearing in mind that only inactive or expired pages are eligible to be dropped/swapped, we can see that the situation you describe will never happen.
The behavior of, from the user's perspective, what applications get shoved out of active memory (regardless of whether they end up in the swapfile or in /dev/null) doesn't change. In the same way that the Linux VMM will never drop pages associated with an active process (such as the email sync service, the Wifi driver, etc), the Linux VMM will likewise never swap these pages out either.
Why spend the cycles swapping things in and out of RAM? There is plenty of memory on these devices to support all the services and memory hungry games. If some game has a memory leak, you SHOULD be getting errors from running out of memory and NOT blissfully swapping things to flash.
Click to expand...
Click to collapse
Consider the scenario you spelled out previously - without the swapfile, the pages associated with the Browser app will get dropped and make room for Angry Birds. Good news: Angry Birds starts up faster.
With the swapfile, the pages associated with the Browser app will get swapped out to make room for Angry Birds. This will take longer since there's some file I/O involved. Bad news: Angry Birds starts up slower.
So what's the use case for the swapfile? What if you want to go back to the browser again? Without the swapfile, the Browser is gone. You have to launch it - the application binary needs to be read off disk, executed, the heap has to be re-allocated, re-initialized, and program data needs to be populated. The page you wanted is gone - you need to fetch that again. More waiting while it downloads from the server and the HTML code is rendered on the screen.
In this scenario, reading the heap back into memory from the swap file is actually more efficient than recreating it - even if you ignore the obvious benefit of not having to relaunch the app and reload the page, there's substantial overhead associated with relaunching the app.
So that's the use case - maybe it's not applicable to you if (although maybe someone who wants to go back and forth between Angry Birds and a cheat guide on a G1 might appreciate this) but if you are multitasking across several memory-intensive apps, then the benefit of not having to re-invent the wheel, so to speak, to recover the application state can outweigh the cost of paging the application state out to disk.
I'm not going to tell people how to use their devices. I'm going to try and give them advice, but I certainly can't force people to take it. As a matter of fact, I'll even encourage the technical minded to explore and break things to learn on their own.
However, when a person asks the question I see in the OP, and admits that they are new to linux, then I suspect that they aren't technically minded and exploring, but blindly following the "suggestion" of someone else who promises all kinds of silly things. It reminds me of someone who disabled kernel panic reboots and claimed that it was a tweak to make the system more stable... and had many people actually believing that.
Click to expand...
Click to collapse
I have no problem with dissuading people of the notion that some hack is going to instantly and unequivocally make their system better. But I think the proper response, especially on a forum like this, is to present the facts of the matter and not just a knee-jerk contrarion reaction. Simply dismissing the swapfile as a "BAD THING" doesn't really help the OP learn more about it, at the very least.
I'm with you on disabling kernel panic reboots, though. That's just stupid.
There's a good reason why google hasn't enabled swapping, and there's even less of a reason with devices that come with 1GB of RAM.
Click to expand...
Click to collapse
Maybe, maybe not. Android 2.1 and earlier didn't implement JIT. Android 2.2 and earlier didn't implement EXT4. Android 2.3 and earlier didn't implement GPU-accelerated UI compositing. Android 3.2 and earlier didn't implement ASLR. Does that mean these were considered undesirable by Google at one point in time? Or were they always on Google's list of things they wanted to do and they just hadn't gotten around to them yet?
---------- Post added at 01:56 AM ---------- Previous post was at 01:41 AM ----------
danielkaboom said:
still failed,...:
- create a file in /data (named swapfile.swp), using terminal
# dd if=/dev/zero of=/data/swapfile.swp bs=1024 count=128000
- check from root explorer, the file is now created.
# mkswap /data/swapfile.swp
# swapon /data/swapfile.swp
swapon /data/swapfile.swp = Function not implemented
any sugestion?
edit : the permission is now can be change to rw-r--r--(thx Gary)..but its still failed to swapon,..
edit 2 : from what i've read from other pages and sites,..is it because "kernel not support"?
Click to expand...
Click to collapse
Yes, the kernel needs to have swapfs support. If you've ever played around with EXT4 kernels or ROMs that required EXT4 kernels, for example, it's kind of the same idea.
It sounds like the stock GT7+ kernel does not have this so you will need to find a custom kernel that does. I'm going to go out on a limb and guess that garyd9's kernel does not support swapfs.
Without the kernel, you're out of luck.
Regarding your situation on your Tab, it sounds like you've got an app or two that's misbehaving. Have you tried throwing up a CPU monitor? It would be useful to know whether the slowdown is caused by the CPU getting busy, and whether this load is from a single app or not.
Thank you for explaining that. Are there any examples, other than the one you mentioned, in which Android would benefit from a swapfile?
reading both pros and cons about swapfile really makes my head spinning,... im trying to understand it little by little. thanks guys for the explanation.
and yeah, guess im run out of luck,..(cause i don't have enough skill to make the kernel on my own,..sigh).
thanks.
danielkaboom said:
reading both pros and cons about swapfile really makes my head spinning,... im trying to understand it little by little. thanks guys for the explanation.
and yeah, guess im run out of luck,..(cause i don't have enough skill to make the kernel on my own,..sigh).
thanks.
Click to expand...
Click to collapse
It is a complicated issue with lots of tradeoffs in both directions.
I'm still curious as to the specifics of your problems, though. Garyd9 is correct in saying that creating a swapfile may not help your particular issue but that doesn't mean there isn't some other way to fix it. We just need more information about what's going on on your tablet.
---------- Post added at 05:49 PM ---------- Previous post was at 05:29 PM ----------
nyarltep said:
Thank you for explaining that. Are there any examples, other than the one you mentioned, in which Android would benefit from a swapfile?
Click to expand...
Click to collapse
Fundamentally, it breaks down to a store vs. recalculate issue - do you store memory pages to the swap file and incur the storage I/O overhead or do you discard it and recalculate it later and incur the cpu and memory I/O overhead? All of these resources are in short supply on the GT7+.
A swapfile works best with applications that maintain steady states that can easily be swapped out and back in as needed. A swapfile is least effective for active background processes.
If, for example, you're running out of memory running too many apps in the background - think clients for sync services, streaming media, system monitoring, etc. - a swapfile is not going to help.
However, if you're running into situations where you are switching between multiple apps such as document viewers/editors, and are finding that you need to reload documents as the apps get silently killed in the background, a swapfile could potentially help.
The only real way to know is to test it but without a kernel with swapfs support for the GT7+, it's impossible to say for certain.
from the opinion, i guess using swapfile for backround process is useless, but using it to switching task (for example : im using browser with lot of pages and beside that im doing some paperwork on office aplication) will help a bit, am i r8? if its r8, then im willing to try using swapfile, because i already freeze/uninstall some aplication that running on backround but still give me lags, when i did the example above.
but again, im running out of luck,..until Garyd9 or any1 else kind enough to make kernel that support swapfs,...
thanks for both of you, for your effort to answering my noob question.
regards,
dan
PS : Gary, i've tried your instruction, and yes it makes my daily use better,...though im still curious using swap,...hehehe.
danielkaboom said:
from the opinion, i guess using swapfile for backround process is useless, but using it to switching task (for example : im using browser with lot of pages and beside that im doing some paperwork on office aplication) will help a bit, am i r8? if its r8, then im willing to try using swapfile, because i already freeze/uninstall some aplication that running on backround but still give me lags, when i did the example above.
but again, im running out of luck,..until Garyd9 or any1 else kind enough to make kernel that support swapfs,...
Click to expand...
Click to collapse
Background processes are fine to swap out if they're steady state, it's active background processes that aren't going to benefit from a swapfile.
However, the lags you're experiencing may continue to persist depending on what is causing those lags. A swapfile won't help if you've got a poorly-optimized app running, particularly one that is not efficient with memory allocations. It also won't help if the lags are caused by a Dalvik thread performing garbage collection on its heap (whether the app on that thread is efficient in its memory allocations or not).
My educated guess is that if you are experiencing lags while using an active, foreground application, then this is not a problem that will be fixed with a swapfile. On the other hand, if you are experiencing lags launching new applications or bringing background apps into the foreground, these types of lags may be reduced with the use of a swapfile though the only way to know for sure is to test it.
I don't have time for an indepth reply to h2g2, but I'll reply simply:
You seem to be knowledgable enough to recompile a kernel - so please feel free to pull my kernel sources and initramfs, turn on swapping (samsung has it disabled by default), and try it. Keep an eye on the swapping and memory stats, as well as what's being swapped, etc... You might be surprised.
(If I had time, I'd do the same.. I've been wrong before and I might be wrong again... )
In either case, Daniel, I'm glad that turning off all that excess crap helps. As much as we all complain about this tablet, it actually runs pretty good without many modifications. If you read the changes I've made in the p6210 kernel, you'll see that I really haven't done much to it. The most invasive change was adding stuff that Samsung didn't have in there (such as UV.)
Take care
Gary
garyd9 said:
I don't have time for an indepth reply to h2g2, but I'll reply simply:
You seem to be knowledgable enough to recompile a kernel - so please feel free to pull my kernel sources and initramfs, turn on swapping (samsung has it disabled by default), and try it. Keep an eye on the swapping and memory stats, as well as what's being swapped, etc... You might be surprised.
(If I had time, I'd do the same.. I've been wrong before and I might be wrong again... )
Click to expand...
Click to collapse
Just to be clear, I have no real stake in this except to make sure that the technical facts about the swapfile are presented properly. In much the same way that you've been frustrated hearing about people recommending that they disable kernel panic reboots, I also am frustrated when people have a knee-jerk "swapfile = terrible" reaction that is largely based on FUD.
That said, you're right, I should just test it myself when I've got some free time.
Dusted off my old Nexus One, loaded up a clean install of CM7 and installed a kernel with CONFIG_SWAP=y. I decided to go with a swap partition on my sd card rather than a swapfile but the effect should be the same.
I haven't had time to do extensive testing but so far but I can confirm that swap is working and I haven't yet noticed a major perceptible impact to performance of the device.
Code:
# free
total used free shared buffers
Mem: 403240 379288 23952 0 60
-/+ buffers: 379228 24012
Swap: 62696 27948 34748
# grep "pswp" /proc/vmstat
pswpin 192
pswpout 7059
---------- Post added at 01:37 PM ---------- Previous post was at 12:49 PM ----------
Been switching back and forth between apps for a while now, paying particular attention to apps like Google Earth and the Browser that load up lots of data.
One particular test that seemed to stress the memory subsystem was using the "Print this page" on multi-page articles on graphics-heavy sites like, e.g. Anandtech (had the Snapdragon S4 review up). With swap enabled, there was a delay of 1-2 seconds when switching back to the browser (no doubt from reading the appropriate pages back into memory) but without the swapfile, the session was gone and the page needed to be reloaded, which took much longer than 1-2 seconds.
Some caveats:
1) I used a rather small swap partition (64MB) compared to the amount of memory available on the device (512MB for the N1). This means that I didn't need to do too much tweaking to the lowmemorykiller settings.
2) I set swappiness to 100, which is intentionally a bit heavy-handed (default seems to be 60).
3) I did not tweak other settings such as dalvik.vm.heapsize, vfs.
_cache_pressure, page-cluster and, as mentioned in #1, lowmemorykiller/parameters/minfree.
Code:
# free
total used free shared buffers
Mem: 403240 390824 12416 0 36
-/+ buffers: 390788 12452
Swap: 62696 59684 3012
# grep "pswp" /proc/vmstat
pswpin 6061
pswpout 31228
h2g2 said:
Dusted off my old Nexus One, loaded up a clean install of CM7 and installed a kernel with CONFIG_SWAP=y. I decided to go with a swap partition on my sd card rather than a swapfile but the effect should be the same.
I haven't had time to do extensive testing but so far but I can confirm that swap is working and I haven't yet noticed a major perceptible impact to performance of the device.
Code:
# free
total used free shared buffers
Mem: 403240 379288 23952 0 60
-/+ buffers: 379228 24012
Swap: 62696 27948 34748
# grep "pswp" /proc/vmstat
pswpin 192
pswpout 7059
---------- Post added at 01:37 PM ---------- Previous post was at 12:49 PM ----------
Been switching back and forth between apps for a while now, paying particular attention to apps like Google Earth and the Browser that load up lots of data.
One particular test that seemed to stress the memory subsystem was using the "Print this page" on multi-page articles on graphics-heavy sites like, e.g. Anandtech (had the Snapdragon S4 review up). With swap enabled, there was a delay of 1-2 seconds when switching back to the browser (no doubt from reading the appropriate pages back into memory) but without the swapfile, the session was gone and the page needed to be reloaded, which took much longer than 1-2 seconds.
Some caveats:
1) I used a rather small swap partition (64MB) compared to the amount of memory available on the device (512MB for the N1). This means that I didn't need to do too much tweaking to the lowmemorykiller settings.
2) I set swappiness to 100, which is intentionally a bit heavy-handed (default seems to be 60).
3) I did not tweak other settings such as dalvik.vm.heapsize, vfs.
_cache_pressure, page-cluster and, as mentioned in #1, lowmemorykiller/parameters/minfree.
Code:
# free
total used free shared buffers
Mem: 403240 390824 12416 0 36
-/+ buffers: 390788 12452
Swap: 62696 59684 3012
# grep "pswp" /proc/vmstat
pswpin 6061
pswpout 31228
Click to expand...
Click to collapse
little of my understanding, if a swapfile is made in an external sd, the sd card must have good r/w capability (minimum required a class 6 sd card), what if the swapfile is made in internal sd (since GTab have 12gb planted chip memory), what is the effect?
and so,....would you be kind enough to build a kernel for GTab 7+ that support swapfile? and if you do, can you do with a flashable zip (which i can flash it through cwm recovery?
so i can answer my own question : swap or not to swap?
and of course if you have spare time
thanks
dan
danielkaboom said:
little of my understanding, if a swapfile is made in an external sd, the sd card must have good r/w capability (minimum required a class 6 sd card), what if the swapfile is made in internal sd (since GTab have 12gb planted chip memory), what is the effect?
and so,....would you be kind enough to build a kernel for GTab 7+ that support swapfile? and if you do, can you do with a flashable zip (which i can flash it through cwm recovery?
so i can answer my own question : swap or not to swap?
and of course if you have spare time
thanks
dan
Click to expand...
Click to collapse
I'm using a Class 2 8GB MicroSDHC card from Sandisk on my Nexus One for testing and it seems to be fine. I'd recommend using an external SD because it's replaceable and swap I/O will wear out your flash faster so you're better off segregating it.
I took a look at the state of the kernel source for the GTab7+ at the moment and it looks like the Samsung sources are out of date and a kernel built from the current sources won't run properly on the LA3 firmware (Garyd9 notes this in the thread for his kernel as well) so right now, building a custom kernel is a nonstarter for me because the LA3 firmware fixed some pretty major shutdown issues for me on my Tab.
Perhaps when the ICS sources are released, I'll take another look.

OOM Grouping

Did any of you have any experience with OOM groupings in Android?
It would be interesting to discuss it here and find a perfect tweak for our Infinity/ies.
Please explain what this is, I've never heard of it.
http://madsquirrelapps.wordpress.com/2010/06/24/what-are-oom-priorities/
Out of memory grouping is Androids way of saving ram by killing applications, when your ram is getting full. When setting prioritys, you can prevent this happening for certain applications.
Nahakiole said:
http://madsquirrelapps.wordpress.com/2010/06/24/what-are-oom-priorities/
Out of memory grouping is Androids way of saving ram by killing applications, when your ram is getting full. When setting prioritys, you can prevent this happening for certain applications.
Click to expand...
Click to collapse
Oh, that's interesting. I didn't think that this tablet could really have a hard time with memory though, I don't have it on my Bionic.
For now I'm only using apps from the market to change the minfree values (could be done from commandline, but I like to have GUI for that, as it's less likely I'll mess it up). I followed the values proposed by the author of SuperCharge (which are also not his, but use some minfree calculator) for 1GB RAM and set it to 8,16,200,220,240,275 (explanation here: http://forum.xda-developers.com/showthread.php?t=622666)
But there are other tweaks that can be done with it, I believe, that's why I asked..

[Q] RAM Manager? (edit: Heap size)

I recently had a couple of issues with an app called "TouchDraw". The problem was that, on occasion, the app would fail to load certain images because of low memory, and would insert placeholders instead.
This happened even though I have over a gig of free RAM available.
So I contacted the app developer, to see if it was a bug or something, but it turns out (according to them anyway) that android by default only allows apps to use up to a maximum of like 256mb of RAM, no matter how much RAM is actually available. They also said there was nothing they could do about this from their end, and the only way round it was to root.
Fortunately, I have my Note rooted already, so:
Is there a universally recommended RAM management app that I should be using? I have looked and found a few, but I'm unsure on the differences. A lot of them were reviewed based on phones and difference uses... Seemed safer to ask first.
Thanks!
Edit: actually it turns out its the heap size I need to change. Seems there is a tool called "vm heap tool" that does this... But only on older devices with small heap sizes. Need to find an alternative!
any recommendations?
Minfree manager
Sent from my HTC One X+ using Tapatalk 2
AndroHero said:
Minfree manager
Sent from my HTC One X+ using Tapatalk 2
Click to expand...
Click to collapse
Hmm... from what I can see, all that does is close down programs quicker so that I have more free RAM?
I have plenty of free ram, its just that android limits the amount of memory that an app can use. Apparently theres a way around this if you are rooted?
Unless I'm misunderstanding something.
Edit: Plus, minfree seems to be designed for phones? The help/guides I can find for it all seem to deal in tiny amounts of ram (relative to the 2gigs I have)
Edit 2: Hmm, it would seem that I need to increase my heap size... the line "android:largeHeap = true" keeps coming up when I search for the answer to this question. I will have to investigate further!
Edit 3: seems that value is for app debs only perhaps. There was a tool that did what I needed to the default heap values (vm heap tool) but it only supports much smaller heap sizes. Will have to look for an alternative!
nirurin said:
Hmm... from what I can see, all that does is close down programs quicker so that I have more free RAM?
I have plenty of free ram, its just that android limits the amount of memory that an app can use. Apparently theres a way around this if you are rooted?
Unless I'm misunderstanding something.
Edit: Plus, minfree seems to be designed for phones? The help/guides I can find for it all seem to deal in tiny amounts of ram (relative to the 2gigs I have)
Edit 2: Hmm, it would seem that I need to increase my heap size... the line "android:largeHeap = true" keeps coming up when I search for the answer to this question. I will have to investigate further!
Edit 3: seems that value is for app debs only perhaps. There was a tool that did what I needed to the default heap values (vm heap tool) but it only supports much smaller heap sizes. Will have to look for an alternative!
Click to expand...
Click to collapse
Edit 4: Well turns out I managed to do it.. I think. I modified my build.prop, and changed my heap from 256mb to 320mb. Seems to have done the trick! At least, this app hasnt had any more ram issues since.
heap size gt-8020
nirurin said:
Edit 4: Well turns out I managed to do it.. I think. I modified my build.prop, and changed my heap from 256mb to 320mb. Seems to have done the trick! At least, this app hasnt had any more ram issues since.
Click to expand...
Click to collapse
I am noob to android, I have heap size 265mb on galaxy note 10.1, gt-8020, android 4.1.2. not rooted.
I need for photo mate r2 application heap size of minimum 512mb to be able to save edited raw photos to jpg without that application is useless, developer say that heap size is problem and indeed with smaller files (editing) saving is working
can somebody please point to recent root procedure and how to edit my build.prop and change my heap to 512mb
thanks

Categories

Resources