set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
how I can modify it to use the maximum amount of RAM? thank you i appreciate your comments
debulus said:
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
how I can modify it to use the maximum amount of RAM? thank you i appreciate your comments
Click to expand...
Click to collapse
buy another device. You can't increase ram size.
I would have to agree with the above.
TILT 2 Tapatalk
Indeed, we're using all of the RAM on the device, if that's your question.
You cannot drop more RAM in your phone like a PC.
176mb total it's maximum of RAM?
Seems with kernels that i used month ago it be 191mb total.
But devices have 288mb RAM in specs...
DmK75 said:
176mb total it's maximum of RAM?
Seems with kernels that i used month ago it be 191mb total.
But devices have 288mb RAM in specs...
Click to expand...
Click to collapse
I believe that number you're looking at is after everything reserved is taken out... Video memory, etc.
DmK75 said:
Seems with kernels that i used month ago it be 191mb total.
Click to expand...
Click to collapse
Are you getting a message that states 'phone memory running low'? I had that message and Arrrghhh (THANK YOU AGAIN) pointed me HERE to expand the size of my data.img file (I went from 256 to 512) which got rid of the message.
Related
Hi
I bought a 128mb Secure Digital Card from Expansys but when I put it
into my device the Memory on Storage Card says 118.75mb so
where's 9.25mb gone!!!!!
TIA
Charles
The file allocation table (FAT) eats up the rest.
John
And something about..
Secure Digital - This requires space for the "secureness"
So a Multimedia Card may have given you a few megs back..
Its the old saying.
You just don't get what you pay for anymore!
MmF
Missing 10mb
Thanks for the responses.
9.25mb for the FAT, Jeeeez!
Why don't they build them 138mb, and give me what I've paid for!
Rgds
Charles
Actually the FAT does not eat up that much space, not even close. Here's the other part of the reason: A megabyte and a million bytes are NOT equal!
A kilobyte is 1024 bytes. A megabyte is 1000 of those.
The card and hard drive makers say that THEY measure a megabyte as being 1 million characters even. So your 256MB card can hold 256 million characters or bytes.
The computer and PPC however, measures in real megabytes and take that number, dividing it by 1024, to come up with its reported size. Therefore, your card has 256 million bytes, but not 256 megabytes.
They've redefined the word.
Ahh I see now. Thanks Carlos
Rgds
Charles
Here is a thread that seems to be making the rounds throughout the forums...
http://forum.xda-developers.com/showthread.php?t=1010807
Following the guidelines in the thread, here are my results with CM7 using a Kingston 8GB Class 6 card...
Before:
Write - 6.6 MB/s
Read - 15.2 MB/s
After:
Write - 5.8 MB/s
Read - 94.4 MB/s
I would recommend playing with the values to see what works best for your particular SD card... Not quite sure
if it is a placebo type effect, but apps like the Gallery and games that use the SD card are noticeably faster...
Have fun...
I did extensive testing on a patriot class 10 8gb card today.
I had lowest standard deviation on results using 1024 buffer. I also had the highest reads at that buffer with a higher write speed.
I had the highest write speed at 4096, but the read speeds were slower than 1024.
I rebooted several times to make sure that wasn't playing into it, and reran many test. All results were relatively consistent.
~11.6 write
~86 read
@1024
~11.9 write
~79.4 read
@4096
~10.8 write
~71.9 read
@128
The change wasn't huge for me. Most have reported 2048 as the best setting.
Also, I updated my cm7_mod to include this. Working on making it installable w/ the scripting...
http://forum.xda-developers.com/showthread.php?t=1008612
It's only meant to be used with cm7_tablet_tweaks as a base now.
Couldn't such a buffer size setting be usefull for emmc (internal memory) too ?
I'm using dalingrin's OC kernel with the IO issue, and it feels slower than my SD card...
I've commited this tweak already today. I would be interested to find the optimal value for mmcblk0.
Jaostar said:
Couldn't such a buffer size setting be usefull for emmc (internal memory) too ?
I'm using dalingrin's OC kernel with the IO issue, and it feels slower than my SD card...
Click to expand...
Click to collapse
My current kernel should not have any IO issues.
dalingrin said:
I've commited this tweak already today. I would be interested to find the optimal value for mmcblk0.
My current kernel should not have any IO issues.
Click to expand...
Click to collapse
Instructions for tweaking the emmc are in that thread. I wouldn't mind taking the time to test and crunch the numbers but sd tools only wants to test my SD card.
EDIT:
App called J Disk Benchmark 2.0 can test internal memory. Working on testing now.
Uhm... my SD card tests faster...
I hope people don't go over board and incorporate this type of permformance increases in their roms by default based on bench mark tools. there is value in increasing readahead for some access patterns, mainly when doing lots of sequencial reads. the trade off of course is at the expense of memory usage. nook even with its 500mb of memory is still not considered high in memory. setting the readahead to 2mb is quite aggressive and will work well in some work loads like galary when reading lots of files around 2mb in size while in other work loads it may actually have negative affects. I am not saying that this specific tweak is bad because I haven't done any tests myself, but don't always believe the numbers u see from benchmark tools.
I'm only setting it to 1024k. I feel like that is plenty high.
dalingrin said:
I'm only setting it to 1024k. I feel like that is plenty high.
Click to expand...
Click to collapse
Yes 1024 is what I'm running really gave the best all around performance.
I think I found the internal memory and it's set to 128 by default
can't find any real difference between 64 and 4096. That looks like the only other mmc device though, so it must be it.
chisleu said:
App called J Disk Benchmark 2.0 can test internal memory. Working on testing now.
Uhm... my SD card tests faster...
Click to expand...
Click to collapse
Yep, it's the same for me, my Class 6 SD card achieves 6,3/11,6 and the internal memory only 4,86/7,52...
BTW :
J Disk Benchmark 2.0 doesn't use the cache, so this tweak wont affect the results...
Jaostar said:
Yep, it's the same for me, my Class 6 SD card achieves 6,3/11,6 and the internal memory only 4,86/7,52...
BTW :
J Disk Benchmark 2.0 doesn't use the cache, so this tweak wont affect the results...
Click to expand...
Click to collapse
Balls.
I'm going to jack it to 1024 and hope that works then.
OK, I can't get any meaningful numbers anymore. I think yesterday's test was a fluke. I can't get any real changes from 128 to 4096 (or in between) with fast or slow SD cards, big or small, black or dark black.
The write speed on slower cards is lower (5-6mb/s) and the faster cards are higher (10-12MB/s) and read speed for all is 80-90mb/s.
Maybe this is a performance mod not for us?
Hey guys,
I have an HTC One V, which is a pretty low-mem device at 512MB RAM. I've been using a normal 256MB swap partition on my SD card with swappiness set to 100 and default minfree settings. This has already given me fantastic results, now I can switch between 4 running programs without having to reload any of them. Before the swap script 2 was the maximum, and even that wasn't always true. Basically I had no multitasking.
Now, I've been checking my memory usage in detail. It seems that when idle, there is about 80MB of free RAM, and around 80MB of swap space is being used. It seems that even though I have 256MB of swap space available, Android never really goes above using ~80. Is there a setting I can fine tune somewhere that would lead to better use of the swap space? From my limited understanding, it seems that in theory Android could store at least two or three more background apps on the swap partition instead of killing them. Which, of course, would lead to much better multitasking.
I'm also aware that using the full 256 megs might actually hurt performance, but I still want the OS to use more than 80.
Please don't flame me if this question has been asked before, I tried to search, but I only found threads discussing the value of vm.swappiness.
TRY TO USE KERNEL TUNER.
AS WELL AS INCREASE SWAPPINESS TO 128 MB.
BUT OS TAKES ONLY AS MUCH RAM IT WANTS U NO NEED TO WORRY THAT IT IS NOT PROPERLY UTILISED.
Hit thanks.....
caius112 said:
Hey guys,
I have an HTC One V, which is a pretty low-mem device at 512MB RAM. I've been using a normal 256MB swap partition on my SD card with swappiness set to 100 and default minfree settings. This has already given me fantastic results, now I can switch between 4 running programs without having to reload any of them. Before the swap script 2 was the maximum, and even that wasn't always true. Basically I had no multitasking.
Now, I've been checking my memory usage in detail. It seems that when idle, there is about 80MB of free RAM, and around 80MB of swap space is being used. It seems that even though I have 256MB of swap space available, Android never really goes above using ~80. Is there a setting I can fine tune somewhere that would lead to better use of the swap space? From my limited understanding, it seems that in theory Android could store at least two or three more background apps on the swap partition instead of killing them. Which, of course, would lead to much better multitasking.
I'm also aware that using the full 256 megs might actually hurt performance, but I still want the OS to use more than 80.
Please don't flame me if this question has been asked before, I tried to search, but I only found threads discussing the value of vm.swappiness.
Click to expand...
Click to collapse
Disclaimer: This is somewhat speculative.
The vm.swappiness is in principle what you are looking for, talking about Linux swap. Unfortunately, for you right now, the Andorid uses "application level swapping", i.e. the Android ActivityManager (userspace task) kills of app's when the memory gets low. Since Android normally don't utilize swapspace, there's a possibility ActivityManager doesn't looks at the size of the total virtual memory (including backed by swap), but only the physical memory installed. If so, it will continue killing app's at the same memory threshold as before, despite of the increased virtual memory size, hence not utilizing the increased virtual memory particularly well. This sounds as what you are describing.
You'll need to check the source ApplicationManager.java to examine the internals here.
Im specifically after an answer for the swappiness tbh.
Im using Yank kernel and it allows zRam which i usually set at about 300. The swappiness part i dont understand and cant really find any info on it, it has settings going up in steps of 10 from 60 to 100. I set it at 80 but thats only because its in the middle.
Could someone explain to me or link me to something, that isnt too technical, about what these steps are for and what they do for it?
It just means how aggressive it is at forcing things into zram. The higher the number (100), the more forceful it is to use the 300 you set as zram over the normal ram.
Swappiness is usually a term to describe swap bias. As above but towards a swap partition or file. Technically zram and swap aren't the same but the term swappiness works
This is really over simplified but I think it should be sufficient.
Sent from my GT-I9300 using Tapatalk 2
Cheers that'll do me, at least it gives me an idea and I can have a play about with it
I did find this https://groups.google.com/forum/#!topic/linux-sunxi/dYCL84IQH_Yù
In short: changing an option you can have mali do dynamic ram allocation that means it uses only ram that it REALLY needs, not some hardcoded number like 192. So when it is not needing so much ram, system has more free ram. Everyone likes having more usable ram right?
Pasting relevant parts
Siarhei Siamashka said:
After this fix, Mali400 GPU is configured to use up to 256 MiB of
normal memory when CONFIG_SUNXI_MALI_RESERVED_MEM is not enabled.
When CONFIG_SUNXI_MALI_RESERVED_MEM is enabled, it uses 64 MiB of
reserved memory and up to 192 MiB of normal memory (same as before).
Click to expand...
Click to collapse
and this
Mali has MMU and does not strictly need any physically contiguous
memory reservation. Most users will likely prefer more flexible
memory allocation instead of always wasting 64 MiB (even when Mali
is not used or needs much less).
CONFIG_SUNXI_MALI_RESERVED_MEM option is still available and can
be enabled if needed (for performance or some other reasons).
Click to expand...
Click to collapse
I wanted to ask if something like this is doable for our Xperia devices here that have a mali400 (U, Sola, Go and P). And if yes, how can we do this? Or at least try to see if it works.
Is it an option that has to be set in a config file when compiling kernel? Can it be set as build prop or init.d or whatever?
I'm not a dev and I don't have the environment/skill to compile anything so unless it is something easy I'm probably not going to make it myself.
High hopes for this though... :laugh:
@95A31 @percy_g2 @DevSwift1
I looked to our kernel codes now, it's possible to apply it but I don't know, it shouldn't be that easy :/
if the choice of pre-allocating ram for mali was because of "safety" reasons like avoiding potential hacks to pirate stuff or sidestep limitations imposed by licensing or whatever (like for example some of the Xposed Framework's modules that allow youtube content over HDMI port or whatever), it can just be a matter of disabling settings.
Or maybe they pushed it into production before the drivers were stable enough for dynamic ram allocation to work reliably.
Some people running linux on arm boards with a mali400 gpu already recommend to build kernels disabling that option to "maximize available memory".
http://www.malaya-digital.org/make-...-an-external-usb-hard-disk-over-your-network/
pasting relevant part here (note that this is for compiling linux-on-arm kernel and for a different device, stuff may or may not apply to our phones):
9] To maximize available memory, edit .config and look for the line having "CONFIG_CMDLINE". Then edit the line to become::
CONFIG_CMDLINE="[email protected] console=ttyS0,115200 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=8"
10] Look for CONFIG_SUNXI_MALI_RESERVED_MEM, CONFIG_MALI, and CONFIG_MALI400 in .config . Set them to "n" :
CONFIG_SUNXI_MALI_RESERVED_MEM=n
CONFIG_MALI=n
CONFIG_MALI400=n
Click to expand...
Click to collapse
Besides, I don't see why the heck a non-HD-resolution phone must keep 192 mb of dedicated gpu ram when anything else (desktop/laptop or console) can do perfectly fine with full HD resolutions and hardware accelerated h.264 decoding with a crappy card that has only 64mb of ram (and the hardware accelerator, of course).
Make more of a difference if we had a rom that actually used the leaked sources so it doesn't run like ****.
However I'd like this still as I don't game on my phone at all, so it's pointless for the gpu to use so much on mine.
Are there some devs working on it at the moment? It would be just great to have some MB's more RAM
I comparet our kernel with this one and they are totally different. AFAIK is not possible.
95A31 said:
I comparet our kernel with this one and they are totally different. AFAIK is not possible.
Click to expand...
Click to collapse
But it's still in AOSP todo, so we can hope? I think this can radically change our user experience, isn't it?
Our board uses only 32MB of RAM for Mali, not 64MB
Garcia98 said:
Our board uses only 32MB of RAM for Mali, not 64MB
Click to expand...
Click to collapse
then why we have only 392 mb out of 512? i know that some mbs are dedicated to the gpu, but 120mb to gpu????
alexhdkn said:
then why we have only 392 mb out of 512? i know that some mbs are dedicated to the gpu, but 120mb to gpu????
Click to expand...
Click to collapse
In Xperia U 15MB are used for memory debugger, 1MB for shared memory, 16MB for modem, 1MB for ISSW, 64MB (may vary) for hardware, 32MB are reserved for Mali and then 383MB (may vary) are available for the system
Regarding dynamic memory allocation, I don't think that using it would be a good idea, as it can lead to allocation failures, memory leaks and other logical errors. I'm sure that there is a reason why Igloo Community don't apply Mali dynamic memory allocation to Snowball
BTW, you can read here the opinion of a professional about dynamic memory allocation in real time systems: http://www.mentor.com/embedded-soft...10b6e1-f9e9-4d87-8c88-6ced717a9f7a?cmpid=8688 :good:
Said professional even goes further advising against the practice - but yet it landed on sunxi 3.4 branches, with dev even sounding almost shocked by the senselessness of the previous state of affair.
My educate guess is that if Igloo Community never lift a finger, is just because they were axed before such a secondary issue could become relevant, in the grand scheme of things.