You may have noticed the ~1 GB cache partition on 3rd gen HDX devices that was used as temporary work space for chunky FireOS OTA updates. Typically <5% is used by Android which leaves a sizable block of space completely wasted. While it is possible to adjust partition boundaries to to expand either the System or Data partition that task is not for the faint of heart on an Android based device.
One option is to utilize a portion of the Cache partition for eMMC backed swap, especially since the stock kernel does not support zRAM. This can be attractive for those who run large or numerous apps that consume the 1.8 GB of available RAM. While Android's LMK will typically prevent OOM (out-of-memory) conditions under heavy pressure the constant recreation/reloading of killed activities can be annoying.
It is pretty easy to create a swap file in the Cache partition with an app like App2SD (just an example; not an endorsement). Suggest starting with 128 or 256 MB. You may want to crank down the swappiness value (default on most ROMs is 60) to limit write activity to eMMC which has a finite lifespan. Tuning LMK is also part of the game; lots of apps can handle that including the fan favorite L Speed or any of the popular Kernel Manager apps (EK Kernel Manager, Kernel Adiutor, etc).
eMMC backed swap has its pros and cons. While experimenting won't hurt you'll probably want to do a little research before making swap a permanent part of your config.
Enjoy!
edit: A tool like DiskInfo can help illuminate how partitions are allocated/utilized on your device.
FWIW - the following values returned acceptable results for my typical usage scenario:
- LMK thresholds (in MB): 16/32/48/64/80/96
- swappiness: 40
- vfs cache pressure: 70
Edit 04/18: Over time I have stopped twiddling with most VM parameters (accepting default values) as there was not a sustained, meaningful difference in performance to justify maintaining custom settings. However, I have found increasing the LMK "empty app" threshold provides a noticeable increase in response time with light to moderate multi-tasking. New LMK settings as follows:
LMK thresholds (in MB): 16/24/32/48/64/128.
I have found these values work well on most devices equipped with ~2 GB of RAM. In fact setting appropriate LMK values can all but eliminate the benefits of file based swap on this device. Obviously YMMV.
Quick follow-up: The config outlined in the OP remains on my daily driver and continues to enhance the overall enjoyment of this device. Over time I refined a few tunings for my workflow. Difference are subtle but yield better resource utilization. YMMV.
- swappiness: reduced to 20 to further discourage cache file writes
- VFS cache pressure: restored device default (100)
Davey126 said:
Quick follow-up: The config outlined in the OP remains on my daily driver and continues to enhance the overall enjoyment of this device. Over time I refined a few tunings for my workflow. Difference are subtle but yield better resource utilization. YMMV.
- swappiness: reduced to 20 to further discourage cache file writes
- VFS cache pressure: restored device default (100)
Click to expand...
Click to collapse
Hello Dave, I've follow your posts and managed to get 256MB for swap space but used only about 50KB. Is it work or not? How to check does a swap helps a system as android?
BR!
iksel said:
Hello Dave, I've follow your posts and managed to get 256MB for swap space but used only about 50KB. Is it work or not? How to check does a swap helps a system as android?
BR!
Click to expand...
Click to collapse
Likely working...give it time. You will see swap file utilization slowly creep up but will likely remain at a small fraction of the available space. Note: the swap file is reset (flushed) on reboot.
Setting swappiness to 20 discourages the use of the swap file except under high memory pressure. In most cases that is what you want as RAM is several magnitudes faster than eMMC. The benefit kicks in under high memory loads:
- older content in the memory cache can be (quickly) written out to the swap file freeing up RAM for current demands
- context of loaded but less frequently accessed apps is likely to be fully/partially retained avoiding a complete restart
Bumping swappiness to 40 or higher will increase swap file utilization and also change the composition of swapped contents. The default on many devices, especially on low RAM configs and/or those with zRAM, is 100. That aggressive setting will likely hurt overall performance on a 2GB device with no zRAM support (like the HDX).
Keep in mind the swap file resides in an area of permanent storage that goes largely unused on a HDX fitted with a custom ROM (FireOS uses this area for processing OTA updates). If that file were taking space away from the data partition this tweak would be of questionable value.
Davey126 said:
Likely working...give it time. You will see swap file utilization slowly creep up but will likely remain at a small fraction of the available space. Note: the swap file is reset (flushed) on reboot.
Setting swappiness to 20 discourages the use of the swap file except under high memory pressure. In most cases that is what you want as RAM is several magnitudes faster than eMMC. The benefit kicks in under high memory loads:
- older content in the memory cache can be (quickly) written out to the swap file freeing up RAM for current demands
- context of loaded but less frequently accessed apps is likely to be fully/partially retained avoiding a complete restart
Bumping swappiness to 40 or higher will increase swap file utilization and also change the composition of swapped contents. The default on many devices, especially on low RAM configs and/or those with zRAM, is 100. That aggressive setting will likely hurt overall performance on a 2GB device with no zRAM support (like the HDX).
Keep in mind the swap file resides in an area of permanent storage that goes largely unused on a HDX fitted with a custom ROM (FireOS uses this area for processing OTA updates). If that file were taking space away from the data partition this tweak would be of questionable value.
Click to expand...
Click to collapse
Good to know, thanks again!
Davey126 said:
Quick follow-up: The config outlined in the OP remains on my daily driver and continues to enhance the overall enjoyment of this device. Over time I refined a few tunings for my workflow. Difference are subtle but yield better resource utilization. YMMV.
- swappiness: reduced to 20 to further discourage cache file writes
- VFS cache pressure: restored device default (100)
Click to expand...
Click to collapse
Yet another update. After making modest tweaks to dirty/dirty background ratios I noticed a subtle increase in momentary (<1 sec) lag switching between previously loaded apps. Such behavior is symptomatic of increased memory cache pressure and potentially unnecessary swapping and/or LMK activity. Flushing the cache cured that (for awhile) but is clearly not the ideal solution. Ultimately bumping swappiness to 40 addressed the problem. Guessing the previous value (20) allowed stale application pages to remain in memory a bit too long increasing cache pressure which became evident when actively multitasking.
Bumping this thread as reminder/reinforcement of the beneficial effects for some workflows. In short, a small static swap file significantly improves the multitasking UX if returning to previous app context is important. Newer devices leverage zRAM for this purpose; HDX kernel doesn't support that.
Over time I have gravitated back to defaults for swappiness, dirty timeouts, cache pressure, etc as custom values did not yield significant measurable (or subjective) improvement to warrant changing. Less knobs to turn/tweak which is always good thing in my book!
This is what I usually do - just resize and move the extra space to userdata partition. If only the days of roms that are installed by simply extracting the files on to system partition still continues, we could get some space of the system partition out too :silly:
pipyakas said:
This is what I usually do - just resize and move the extra space to userdata partition. If only the days of roms that are installed by simply extracting the files on to system partition still continues, we could get some space of the system partition out too :silly:
Click to expand...
Click to collapse
Yep - done that too on some devices. Resizing partitions is not for the faint of heart which is why I opted to excluded it from the guide.
I had kown how deal with it ,we can rest our disk partition to make it change to data
I had kown how deal with it ,we can rest our disk partition to make it change to data or system to use!!!
Davey126 said:
Yep - done that too on some devices. Resizing partitions is not for the faint of heart which is why I opted to excluded it from the guide.
Click to expand...
Click to collapse
Why not provide that info? It is no different than flashing custom roms. You are warned by the devs that doing so brings a risk of bricking your device...proceed at your own risk.
I think it would be valuable to those that want to use that wasted space or optimize the use of the storage space available.
Hopefully you will reconsider.
droiduzr2 said:
Why not provide that info? It is no different than flashing custom roms.
Click to expand...
Click to collapse
lol - not comparable, at least with the vast majority of mobile devices that I have been exposed to. Including this one. Those who wish to muck with resizing Android partitions will find copious detail on the net...usually from those who have spent 100X the initial resizng effort trying to recover their device. Because, ya know, it is no different than flashing custom ROMs.
Davey126 said:
lol - not comparable, at least with the vast majority of mobile devices that I have been exposed to. Including this one. Those who wish to muck with resizing Android partitions will find copious detail on the net...usually from those who have spent 100X the initial resizng effort trying to recover their device. Because, ya know, it is no different than flashing custom ROMs.
Click to expand...
Click to collapse
I am pretty sure everyone on here that goes to flash a rom (change from stock) read the disclaimer and assume the risk that they can brick their device. If there were a tool or clear directions to optimize the use of storage space considering we are stuck with 16gb (no usb otg support, no external sd card) then being able to use every Mb much less Gb seems to be a helpful thing imo.
Also it's not about mucking around with just any Android device, it's about this specific device and what one would have to do.
If you are saying it is not an easy task then so be it.
Related
Hi all,
i have read all i can find on the forum on this topic and i wanted to ask is a specific procedure existed for determining a memory leak (if i have one!) i find the gwes.exe file starts at 12mb at boot and generally increases untill a soft reset. it can reach 18mb. whilst i am not sure if this effects performance it causes my memory usage to rise constantly for no reason i can determine!
my setup - rom miri wm6.5 v26.3 - premium WITHOUT manilla
interface - spb mobile shell
dialer - phone ex
not much else
any ideas hints kindly recieved!
regards
Mat
lemat1 said:
i have read all i can find on the forum on this topic and i wanted to ask is a specific procedure existed for determining a memory leak (if i have one!) i find the gwes.exe file starts at 12mb at boot and generally increases untill a soft reset. it can reach 18mb. whilst i am not sure if this effects performance it causes my memory usage to rise constantly for no reason i can determine!
Click to expand...
Click to collapse
GWES memory consumption growth is as natural as gravity and it happens to improve performance. This happens because it is smart enough to keep resources in fast RAM so that next time they will not be loaded from (comparatively slow) flash memory. Basically this is the point in having RAM and the reason why you paid for it - it has to be loaded with stuff to make things faster. This sport of freeing RAM is just ridiculous in most cases (although not always, of course). You pay for it and then don't use.
Secondly, what you describe is not a memory leak. A memory leak is a situation of uncontrolled memory usage growth (if your GWES gradually ate all available memory to a point where device would crash that would be a memory leak). In general, there's nothing wrong with applications consuming more and more RAM as they work as long as they can free this RAM on demand. See for yourself: on your PC, load a memory-hungry application such as a web browser, note how much RAM it uses initially. Then use it for a while, RAM consumption will grow. Then minimize it and see how RAM usage drops dramatically. Even if an application uses half of all RAM it doesn't mean that this RAM isn't available for other programs when needed. When it's not needed, why not use it?
I should know this by now , but I dont.
512 rom leaves us with roughly 190mb for App storage depending on cache correct ?
What about free memory in task killer Showing only 66mb free. With only a few apps running. Is the new OS that heavy ?
KOF33 said:
I should know this by now , but I dont.
512 rom leaves us with roughly 190mb for App storage depending on cache correct ?
What about free memory in task killer Showing only 66mb free. With only a few apps running. Is the new OS that heavy ?
Click to expand...
Click to collapse
Android isn't like Windows. It maximizes the use of whatever memory you have. It's very rare that you'll ever see a lot of free memory (I never have on the G1, even after a reboot). The reason why, is that Android keeps the apps in memory until it starts to run out of room, then frees up memory as needed. This also makes it much faster if you end up opening up an app that's already in memory. In short, don't worry... 66mb free is a good thing.
Actually, the current firmware does not support the full 512Mb. It only supports about 200Mb.
A future kernel update will allow access to more of this (also, radio/screen/etc take some of the physical memory).
bbsydney said:
Actually, the current firmware does not support the full 512Mb. It only supports about 200Mb.
A future kernel update will allow access to more of this (also, radio/screen/etc take some of the physical memory).
Click to expand...
Click to collapse
Can you link to where you got this information?
Roughly 220MB is available to userspace in the shipping build (ERD79).
Quite a lot of memory is dedicated to the radio firmware (41MB), dsp firmware (32MB), display surfaces (32MB), gpu (3MB), camera (8MB), a/v buffers (41MB), and dsp buffers. Much of this needs to be set aside for these specific tasks due to hardware requirements of very large physically contiguous buffers which can be difficult or impossible to obtain after boot once the physical memory space gets fragmented.
The big limitation though is that the Linux kernel needs to do a 1:1 physical:virtual map of general purpose memory used by the kernel and userspace (which excludes the special purpose stuff described above). This eats into the available kernel virtual address space, which is also needed for cross process shared memory used by the binder, etc. Run out of virtual memory and things get unhappy.
In 2.6.32, HIGHMEM support for ARM will allow us to avoid this requirement for a 1:1 mapping which will allow us to increase memory available to userspace without running the system out of virtual memory adddress space.
swetland said:
Roughly 220MB is available to userspace in the shipping build (ERD79).
Quite a lot of memory is dedicated to the radio firmware (41MB), dsp firmware (32MB), display surfaces (32MB), gpu (3MB), camera (8MB), a/v buffers (41MB), and dsp buffers.
Click to expand...
Click to collapse
Thats like 200mb already. What about older phones with only 192mb and 256mb of ram?
I assume older phones will use less ram in the radio firmware and dsp firmware. So why does the N1 require so much more in the radio firmware and dsp firmware etc..?
The radio firmware is also 41MB on all previous devices.
The QSD8250 uses a new DSP which requires an additional 32MB (the 7k devices do not have this requirement). Due to the display having ~2.5x the pixels, window bitmaps are larger and that region grew from 16MB to 32MB to compensate. 720p h264 decode with the new DSP requires quite a lot of memory (41MB worst case, thus the a/v buffer size).
THANK YOU for the clear explanation. So, a later kernel/ROM release should make the unit even "faster" (that is, able to use more RAM and possibly have more things cached), correct? If so, that's sweet.
Hello.
Right now I am on Cyanogen 4.2.15.1.
The biggest problem of G1 is imho lack of memory. I did every possible hack to make more memory available to my phone. I use compcache, 10mb hack etc..
I also tried swap, but it has been giving me some troubles and I find my phone working better without it.
I see everybody switching to 2.x roms and of course it makes me want to switch too although my phone runs pretty fine as it is now. But I would switch if I am convinced that things will improve. So here come the questions:
Did you experienced speed improvement by switching or it just runs the same/slower? (I am only interested in answers of G1 users as this is somehow a bit specific phone with the lack of memory)
My second question rose from my concerns of memory too. To use 2.x roms, one has to use DangerSPL, right? I am not sure about this, but I got the impression, that this one moves some of the memory from application runtime to rom space, so we can fit larger roms in. Does that mean, that in the end this rom has less operational memory for itself? Because that would be the exact opposite thing to what I want to do.
Thanks for the answers.
You as many others are confusing persistent storage with ram.
Ram is fast but will not store data over a reboot.. the amount of ram on the dream remains the same regardless of the spl/radio/rom (with maybe an exception of the 10mb hack that borrows 8mb from video ram for general use)
The persistent storage slow and is what danger spl changes.. this is the equivalent of your hard drive on a computer.
In the case of danger spl it significantly reduces the temporary space (cache) and increases both the core system storage (system) and the user space storage (data) this allows more on internal phone storage instead of the sdcard, having your core apps not using apps2sd is likely to increase perceived speed.
Since the memory (ram) is unchanged and the new kernels are better at memory management there is potential for newer versions to support more tasks at the same time than the older versions. (We are not there yet but cm-5.0.8-test4 and cm-4.2.15.1 seem similar in behavior in terms of what can be done with the ram avalible)
As for upgrading that's your choice.. in general on the dream anyway I don't recommend going to cm5.0.7 and related roms if you have not already done so.. and I never recommend a test version if you are not looking to be a tester. So I'd wait till cm5.0.8 final and related roms are pushed if you feel it's time to upgrade.
Otherwise if you are on a stable 1.6 rom that fills your needs and want to keep a very stable phone.. there is no need to rush the upgrade.. at some point you will find something that requires you to upgrade to 2.1 and will be glad it exists as it will improve the usefulness of the phone.. and I'm sure the stability of 2.1 will only improve over time.
Thank you for your answer.
I of course understand the difference between ram and persistent storage (rom?). The information I missed is that the additional memory is taken from the cache. Someone somwhere here posted something that implied that it reduces ram. Hackery!
Thank you for clearing that up. What are consequences of having less cache? Is this not a problem then?
You got my point with stable 1.6. I do not want to flash new rom every week and prefer stable working phone. The ONLY thing I was hoping for is the better memory management and maybe the whole rom footprint in ram, leaving more room for apps instead of system. I am running apps2sd but I think the main source of sluggishness of my phone is that apps are too often removed from ram by dalvik.
So I was hoping for something like " Yep, 2.1 is 50mb in ram instead of 80mb of 1.6 and you will have more free memory." That would make me switch. Having the same amount or even less makes no sense for me. I see no killer 2.x feature that I need to have so far.
Same amount of ram with both spls as I said. No 10mb hack on cm5 because the gpu is used for system operations
Cache is mounted as /cache and as I said contains temporary and cached data.. As designed its intended as a staging area, which will usually persist across reboots but may not under certain situations.
No performance impact ought to exist due to the resize. If too many things are attempted to be saved here you will get out of disk space errors.. but 30mb is plenty for the staging operations required by the system during normal operation.
As you may know: Linux never has "free" memory.. but reclaimable memory.. the reason for thus is anything read from persistent media is put into "disk cache" in case its needed again.. if the memory is needed for something else it will be freed at no/little cost, but if the cached files are needed they wont be reloaded thus saving the time reading disks/SD/flash.
(Thus why devs cringe when people show the output of free.. 'cat /proc/meminfo' will give full detailed breakdown of memory use if you qknow how to read it)
I am Linux guy myself, so I know how it manages the memory. Anyway, 10mb hack was a huge thing for me, can not live without it.
That pretty much means I am staying and 1.6, thank you for your time.
So...there have been some reports going around on reddit and, here I guess, that increasing readahead will make your sd card faster, and maybe some of you noticed that on my build from early March that I had changed the default readahead values as well. And, the truth is, that it generally does, but the reason the mainline kernel tree doesn't have a higher readahead value isn't because some kernel "developers" here are smarter than Linus and everyone else, but because it is generally a bad idea, and the way some kernel "developers" have implemented it, it is an almost unbelievably stupid way to do it.
So, to give a little background about why the way some people implemented it is a really bad idea...readahead works like this - when you need a section of data from the disk, the kernel will grab that data, and anticipating you'll also use the next X number of kb, it will also grab that data as well and put it into memory. So, when you're doing something like listening to music, or copying data from an sd card (ie long sequential file reads), having a larger readahead is a good thing, and will speed up the process and make things more efficient. But when you aren't doing long sequential reads, you end up thrashing your data. In other words, if you set the readahead value to, let's say 1024kb on /system, every time you access a file you're reading ahead the data that you need, plus and additional 1024kb, or to the end of the file (wouldn't make much sense to read ahead past the end of a file). If you don't end up using that 1024kb it gets flushed from memory, and you read ahead on some other file by 1024kb. You don't end up using that section of data from readahead, it gets flushed, etc, etc. It's a tremendously stupid waste of resources to read ahead that much when you aren't using it. I mean, there's a reason why some of these things are tunable in the kernel and not set to higher values.
And if you want some serious proof check diskstats. With readahead set to 128kb on /system, I still have less than 10% of reads merged. If you only have 10% of reads merged with a 128kb readahead, why on earth (unless you don't know what you're doing) would you want to increase readahead to 1024kb?! To take this one step farther, with readahead set to 4kb, I still only have about 1/3 of the reads merged.
Isn't there a better way to increase readahead?
Yes. The better way is to use Wu Fengguang's series of patches found here http://lwn.net/Articles/372281/. The end result of these patches is that /system, /cache and /dbdata have readahead values of 4kb, /data and your internal and external sd cards have readahead set to 512kb. If you want to take it a step farther and increase it to 1024kb (or whatever value you happen to like - note that you get to a point where you don't get any more throughput, I wouldn't go beyond 1024kb personally), you can do it manually at
Code:
echo XXXX > /sys/devices/platform/s3c-sdhci.0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/queue/read_ahead_kb
(internal) and
Code:
echo XXXX > /sys/devices/platform/s3c-sdhci.2/mmc_host/mmc2/mmc2:bf2e/block/mmcblk1/queue/read_ahead_kb
(external).
What I do is have scripts set up in Gscript lite to increase and decrease readahead, but I don't even use these all the time. Also, if you don't want to flash kernels just to do this, you can set the readahead value for any drive manually, just like for the sd cards,
Code:
echo XX > /sys/devices/virtual/block/stl9/queue/read_ahead_kb
(/system)
Code:
echo XX > /sys/devices/virtual/block/stl10/queue/read_ahead_kb
(/dbdata)
(no point in increasing readahead on /cache, and really, really, really no point in doing it on bml or the other block devices...lol).
In other news...I promise I'll be back soon. I bought a house partially on a whim, partially to spite my girlfriend, and I've been rather busy tweaking the place I live in instead of my phone. But, I just started sorting through the patches I made to my personal sources and I will hopefully have it done tonight...(I know, I've said that many times before, but this time I'm serious...I think)
edit - as an aside, if you've ever wanted to have your display be at the lowered light setting that it switches to just before the screen automagically shuts off, you can control that as well at
Code:
echo 1 > /sys/devices/platform/s3cfb/spi_gpio.3/spi3.0/backlight/s5p_bl/brightness
it doesn't have to be 1, any value from 1-20 seems to have the same brightness, to my eyes at least. Again, I have this set up as a script in Gscript and if I want to dim the display a bit more I run this script...you have to use it every time you unlock the display or if you get close to the screen timeout limit and then touch the screen again.
good read and explanation. thanks
im guessing the new kernel will have the above mentioned readahead mods? cant wait!
Thank you man. This is the only useful description about readahead I've ever read and confirms that kernel default value is not so stupid as it looks.
so, is it a good idea to increase readahead if the only files on the sd card are mp3's, jpeg's and documents?
npt1988 said:
so, is it a good idea to increase readahead if the only files on the sd card are mp3's, jpeg's and documents?
Click to expand...
Click to collapse
Yeh, bigger files that are streamed like movies or music will benefit from a higher read ahead. Smaller files like word docs might not.
[null]
just curious to know. will high readahead kb use more battery?
thanks
Hellboy4 said:
just curious to know. will high readahead kb use more battery?
thanks
Click to expand...
Click to collapse
Better to use 128kb for all existing IO blocks.
how increase read ahead cache and sdcard to 2048 in phoenix os
Hello XDA memebers and admin
i need help and very tired
i dont want use L speed in phoenix os for boost phone and speed read and write
i need other apk or code or tweak
please help me
Thanks for this useful post, which reminds me a few years ago every root user wanted to increase readahead. So I built a tool to actually test and compare read-speed when setting different readahead values.
The tool will read the content of the SD card (external or internal storage) up-to a predefined size (100Mb up-to 1Gb) and show resulting speed for various values of readahead (from 128Kb up-to 5Mb).
On a Nexus 4 running Android 4.2, 128Kb and 256Kb were between 20-50% slower, depending on files being read.
On a S10+ running Android 10 however, gain of increasing read-ahead is not so obvious.
I'd be very much interested in results from other devices running various version of Android.
You can get the tool here, and get support here.
Hello -
This issue has been bugging me for a long time. I'm seeking some general information about the Optimus-T (LG P509) and Android design as a whole. My phone is not the latest and greatest and I've resisted rooting. Maybe this pushes me in that direction. But I need to come to a better understanding of what's going on and how things work in general. Hopefully one of you experts can give some advice.
Memory questions: I keep running low on memory in the device which provides for many goofy results when used. I've moved as many apps as possible to the 16gB SD card. The card has a lot of music on it with 3.2 gB remaining - plays great. Android Assistant reports the following memory compliment relevant to my question:
Memory Info(RAM) Used: 247.75mB
Free: 170.41mB
Total Memory: 418.53 mB
Phone Space Info(ROM)
Used: 157.45mB
Free: 42.05mB
Total Space: 199.5mB
Observations: As I watch the display, the RAM values shift slightly around depending on what the phone is doing at that moment. The values don't fluctuate too wildly at least not from what I observe. I get that part. But... when Phone Space(ROM) drops to the low 20mB level, the device slows to a crawl, often reboots, browser stops and drops back to the home page; all with no error notification. I clear the caches two-three times daily which will raise the ROM value but only by the amount of cache released. I found that keeping around 40mB in ROM provides smooth trouble-free operation. Here's the question: Why is ROM even involved in supporting program code/data operations like this? I've always assumed that ROM (Read Only Memory) by definition is static in nature and thus shouldn't change. Here in Android-land apparently things may not be the same as I understand. So I'm forced into uninstalling some really useful programs (ie Google+) that I like in order to bring the ROM value around the 40mB threshold. I know memory has a finite limit. I don't understand why ROM is even involved and thus why it "flexes". Can someone explain, please?
Look at the amount of available RAM above. Why doesn't the phone use this RAM for program code/data execution? Because I approach this from a Windows/PC background here, perhaps that's what's throwing me off. Still, it's got ample RAM that looks to be unused for the most part. Is there a command or setting (I've looked all over the place) to demand the phone use RAM over ROM? If it did that, I'd have plenty of space and no problem at all.
Given the above, if I stuck having to deal with low ROM, do any of you know if additional ROM/RAM can be added gaining more "Phone Space"? I'm not talking about the SD card; I'm talking about the base memory populated inside the device that serves as that valuable "Phone Space" referred to above?
I'd really appreciate a answer to this. Thank you for your time and any advice.
H
Hoibb said:
Hello -
This issue has been bugging me for a long time. I'm seeking some general information about the Optimus-T (LG P509) and Android design as a whole. My phone is not the latest and greatest and I've resisted rooting. Maybe this pushes me in that direction. But I need to come to a better understanding of what's going on and how things work in general. Hopefully one of you experts can give some advice.
Memory questions: I keep running low on memory in the device which provides for many goofy results when used. I've moved as many apps as possible to the 16gB SD card. The card has a lot of music on it with 3.2 gB remaining - plays great. Android Assistant reports the following memory compliment relevant to my question:
Memory Info(RAM) Used: 247.75mB
Free: 170.41mB
Total Memory: 418.53 mB
Phone Space Info(ROM)
Used: 157.45mB
Free: 42.05mB
Total Space: 199.5mB
Observations: As I watch the display, the RAM values shift slightly around depending on what the phone is doing at that moment. The values don't fluctuate too wildly at least not from what I observe. I get that part. But... when Phone Space(ROM) drops to the low 20mB level, the device slows to a crawl, often reboots, browser stops and drops back to the home page; all with no error notification. I clear the caches two-three times daily which will raise the ROM value but only by the amount of cache released. I found that keeping around 40mB in ROM provides smooth trouble-free operation. Here's the question: Why is ROM even involved in supporting program code/data operations like this? I've always assumed that ROM (Read Only Memory) by definition is static in nature and thus shouldn't change. Here in Android-land apparently things may not be the same as I understand. So I'm forced into uninstalling some really useful programs (ie Google+) that I like in order to bring the ROM value around the 40mB threshold. I know memory has a finite limit. I don't understand why ROM is even involved and thus why it "flexes". Can someone explain, please?
Look at the amount of available RAM above. Why doesn't the phone use this RAM for program code/data execution? Because I approach this from a Windows/PC background here, perhaps that's what's throwing me off. Still, it's got ample RAM that looks to be unused for the most part. Is there a command or setting (I've looked all over the place) to demand the phone use RAM over ROM? If it did that, I'd have plenty of space and no problem at all.
Given the above, if I stuck having to deal with low ROM, do any of you know if additional ROM/RAM can be added gaining more "Phone Space"? I'm not talking about the SD card; I'm talking about the base memory populated inside the device that serves as that valuable "Phone Space" referred to above?
I'd really appreciate a answer to this. Thank you for your time and any advice.
H
Click to expand...
Click to collapse
In answer to your question, I'd like to say that it's just one of those things you'll have to go with(Let me assure you I hate it as much as you do)
Android phones need at least 30~40 MB free space in internal memory to function smoothly...maybe that's just the way they are programmed. That's the reason why phones today come with much higher internal memory...and no, there's no way to make the ram to be used instead or to increase the internal memory. In short-you'll just have to install less apps...or if you root your phone you can try App2SD scripts
Sent from my LG P500 using XDA Premium
Press thanks button if I helped you
Thank you.
So again, I have to change my thinking about how "ROM" here is designed and implemented. ROM (in a PC for example) is certainly used but not in the same way with the same characteristics as used in Android-ville.
And so this tells me, rooting is the last hope for gaining back critical internal (ROM) space so I can have more apps. Again, right now in stock mode, App2SD reports that no further apps can be moved to the card.
I do like this device a lot. It's small, compact and feature rich for what I need. There's lots of good advice on here about the rooting process. It's just "scary" territory as I enter this not knowing if I can avoid the brick.
Thanks again.
H
Hoibb said:
Thank you.
So again, I have to change my thinking about how "ROM" here is designed and implemented. ROM (in a PC for example) is certainly used but not in the same way with the same characteristics as used in Android-ville.
And so this tells me, rooting is the last hope for gaining back critical internal (ROM) space so I can have more apps. Again, right now in stock mode, App2SD reports that no further apps can be moved to the card.
I do like this device a lot. It's small, compact and feature rich for what I need. There's lots of good advice on here about the rooting process. It's just "scary" territory as I enter this not knowing if I can avoid the brick.
Thanks again.
H
Click to expand...
Click to collapse
Rooting your device is actually the easy part, it's possible but unlikely that you will brick it, I had the same thoughts when I done my O1 P500, but now I'm rooted I wouldn't ever go back... I used superoneclick & that had the option to Unroot, I am not sure on other applications because I haven't used them. Basically follow the instructions right down to the letter (re-read or do it when you're wide awake so you don't miss anything), but in my own personal experience rooting it was easy.
Once rooted download the app called "Root Checker Basic" from android market, it should come back saying "This device has root access".
Once rooted you can do so much more, run apps that require root, backup your entire android system, and alot more.
Hope my info helped you, but in all honesty rooting is up to you, don't let anyone else make that choice for you, but just as a side note, rooting will void your warranty then again it's reversible.
Everything written here is based on my own experience and is only intended as a guide.
Hoibb said:
Hello -
This issue has been bugging me for a long time. I'm seeking some general information about the Optimus-T (LG P509) and Android design as a whole. My phone is not the latest and greatest and I've resisted rooting. Maybe this pushes me in that direction. But I need to come to a better understanding of what's going on and how things work in general. Hopefully one of you experts can give some advice.
Memory questions: I keep running low on memory in the device which provides for many goofy results when used. I've moved as many apps as possible to the 16gB SD card. The card has a lot of music on it with 3.2 gB remaining - plays great. Android Assistant reports the following memory compliment relevant to my question:
Memory Info(RAM) Used: 247.75mB
Free: 170.41mB
Total Memory: 418.53 mB
Phone Space Info(ROM)
Used: 157.45mB
Free: 42.05mB
Total Space: 199.5mB
Observations: As I watch the display, the RAM values shift slightly around depending on what the phone is doing at that moment. The values don't fluctuate too wildly at least not from what I observe. I get that part. But... when Phone Space(ROM) drops to the low 20mB level, the device slows to a crawl, often reboots, browser stops and drops back to the home page; all with no error notification. I clear the caches two-three times daily which will raise the ROM value but only by the amount of cache released. I found that keeping around 40mB in ROM provides smooth trouble-free operation. Here's the question: Why is ROM even involved in supporting program code/data operations like this? I've always assumed that ROM (Read Only Memory) by definition is static in nature and thus shouldn't change. Here in Android-land apparently things may not be the same as I understand. So I'm forced into uninstalling some really useful programs (ie Google+) that I like in order to bring the ROM value around the 40mB threshold. I know memory has a finite limit. I don't understand why ROM is even involved and thus why it "flexes". Can someone explain, please?
Look at the amount of available RAM above. Why doesn't the phone use this RAM for program code/data execution? Because I approach this from a Windows/PC background here, perhaps that's what's throwing me off. Still, it's got ample RAM that looks to be unused for the most part. Is there a command or setting (I've looked all over the place) to demand the phone use RAM over ROM? If it did that, I'd have plenty of space and no problem at all.
Given the above, if I stuck having to deal with low ROM, do any of you know if additional ROM/RAM can be added gaining more "Phone Space"? I'm not talking about the SD card; I'm talking about the base memory populated inside the device that serves as that valuable "Phone Space" referred to above?
I'd really appreciate a answer to this. Thank you for your time and any advice.
H
Click to expand...
Click to collapse
GET ADB ON YOUR COMPUTER( GOOGLE IT)
TYPE
ADB SHELL
SetInstallLocation 2
U WILL BEABLE TO MOVE MOST APPS TO SD WITHOUT ROOTING
From the instructions I've googled, it's not clear - do I move them using the phone or do I move them via the computer?
H