This is where our RAM is used

[hardcore]

Hi guys,

Not sure if this has been found yet, but in the dmesg logs you can see how the RAM on the Galaxy S is reserved.

This is from the JPK ROM:

[ 0.000000] S5PV210: PLL settings, A=800000000, M=667000000, E=96000000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x30ec2000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x40204000
[ 0.000000] s5pv210: 14680064 bytes system memory reserved for fimc0 at 0x42604000
[ 0.000000] s5pv210: 1048576 bytes system memory reserved for fimc1 at 0x43404000
[ 0.000000] s5pv210: 12582912 bytes system memory reserved for fimc2 at 0x43504000
[ 0.000000] s5pv210: 16777216 bytes system memory reserved for pmem at 0x332c2000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for pmem_gpu1 at 0x342c2000
[ 0.000000] s5pv210: 1536000 bytes system memory reserved for pmem_adsp at 0x34cc2000
[ 0.000000] s5pv210: 5132288 bytes system memory reserved for jpeg at 0x44104000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for texstream at 0x445e9000
[ 0.000000] s5pv210: 3145728 bytes system memory reserved for fimd at 0x44fe9000
[ 0.000000] s5pv210: 262144 bytes system memory reserved for wifi at 0x34e39000
[ 0.000000] Built 3 zonelists in Zone order, mobility grouping on. Total pages: 117856
[ 0.000000] Kernel command line: console=ttySAC2,115200 loglevel=4
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Memory: 80MB 256MB 128MB = 464MB total
[ 0.000000] Memory: 308048KB available (9224K code, 1910K data, 2868K init, 0K highmem)

I added up all the "system memory reserved for..." lines and got 151,633,920 bytes (144.6MB) reserved.

So the kernel can definitely see about 464MB of RAM in this case, but only 308,048KB is available.

 

[mtoneman]

Hi guys,

Not sure if this has been found yet, but in the dmesg logs you can see how the RAM on the Galaxy S is reserved.

This is from the JPK ROM:

[ 0.000000] S5PV210: PLL settings, A=800000000, M=667000000, E=96000000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x30ec2000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x40204000
[ 0.000000] s5pv210: 14680064 bytes system memory reserved for fimc0 at 0x42604000
[ 0.000000] s5pv210: 1048576 bytes system memory reserved for fimc1 at 0x43404000
[ 0.000000] s5pv210: 12582912 bytes system memory reserved for fimc2 at 0x43504000
[ 0.000000] s5pv210: 16777216 bytes system memory reserved for pmem at 0x332c2000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for pmem_gpu1 at 0x342c2000
[ 0.000000] s5pv210: 1536000 bytes system memory reserved for pmem_adsp at 0x34cc2000
[ 0.000000] s5pv210: 5132288 bytes system memory reserved for jpeg at 0x44104000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for texstream at 0x445e9000
[ 0.000000] s5pv210: 3145728 bytes system memory reserved for fimd at 0x44fe9000
[ 0.000000] s5pv210: 262144 bytes system memory reserved for wifi at 0x34e39000
[ 0.000000] Built 3 zonelists in Zone order, mobility grouping on. Total pages: 117856
[ 0.000000] Kernel command line: console=ttySAC2,115200 loglevel=4
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Memory: 80MB 256MB 128MB = 464MB total
[ 0.000000] Memory: 308048KB available (9224K code, 1910K data, 2868K init, 0K highmem)

I added up all the "system memory reserved for..." lines and got 151,633,920 bytes (144.6MB) reserved.

So the kernel can definitely see about 464MB of RAM in this case, but only 308,048KB is available.

That's interesting. If we take the line:

Memory: 80MB 256MB 128MB = 464MB total as the total memory

So adding it all up:

((464 * 1024 (total memory)) - (9224 + 1910 + 2868 (reserved for kernel) + (144.6 * 1024 (reserved by system) ))) / 1024 = 306 MB (available for apps)

However we should be seeing 512Mb not 464 as the total, so we are missing 48 Mb somewhere.

 

[clubtech]

I still don't understand how the Galaxy Tab sees 444MB for actual applications.

http://www.youtube.com/watch?v=KoOWPjIel-c look at 4:40 in this video. it clearly shows how much RAM the tab is seeing.
Maybe we should poke inside the TAB's firmware to find out what is different?
The hardware is almost 1:1 with the SGS.

 

[TheBeano]

Hi guys,

Not sure if this has been found yet, but in the dmesg logs you can see how the RAM on the Galaxy S is reserved.

Yes, see this thread starting here.

 

[MCOGW]

That's interesting. If we take the line:

Memory: 80MB 256MB 128MB = 464MB total as the total memory

So adding it all up:

((464 * 1024 (total memory)) - (9224 + 1910 + 2868 (reserved for kernel) + (144.6 * 1024 (reserved by system) ))) / 1024 = 306 MB (available for apps)

However we should be seeing 512Mb not 464 as the total, so we are missing 48 Mb somewhere.

It's probably the dalvic-cache!

Because "/system/build.prop" says: "dalvik.vm.heapsize=48m"

Just an idea

 

[drowne]

any improvements if we set an higher value for dalvik heapsize?

 

[flypubec]

It's probably the dalvic-cache!

Because "/system/build.prop" says: "dalvik.vm.heapsize=48m"

Just an idea

This is the max heapsize for a single VM...meaning
the single application can allocate max of 48Mb heap before it gets out of memory.

This has nothing to do with RAM reservation

 

[hardcore]

It's probably the dalvic-cache!

Because "/system/build.prop" says: "dalvik.vm.heapsize=48m"

Just an idea

No its not the dalvik heapsize. Changing that value doesn't give us more usable RAM.

I'm wondering about the Tab too. I was playing with a prototype and it definitely had more accessible RAM, as one poster said - more than 400MB. Would be good to see the dmesg boot log from a Tab to see what the system reserved and total memory is.

 

[mtoneman]

According to this:

http://forum.xda-developers.com/showthread.php?t=792512&page=11


there are one 2GBit (256MByte) and 2 x 1GBit (128MByte each) RAM chips totalling 512MBytes on the board. What we need to find out is why the kernel is reporting "Memory: 80MB 256MB 128MB".
i.e. what happened to the 48MByte on one of the 1GBit modules.

 

[MCOGW]

No its not the dalvik heapsize. Changing that value doesn't give us more usable RAM.

I don't think it's that easy to (really) modifiy this value. I think you need a JTAG to modify this because these are direct parameters for the (smdkc110) chip.
So how did you manage (and verified) this?

 

[neldar]

If you would have read this thread:
http://forum.xda-developers.com/showthread.php?t=792512

You probably have read this:
http://forum.xda-developers.com/showpost.php?p=8325266&postcount=18
Ok it is not directly a "blackhole", but it is reserved.

The SGS kernel config tells you a bit more for what it is reserved:

CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=16384
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=8192
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1800
...
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=12288
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=12288
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=32768
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=32768
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=10240

16 (16384)
+ 8 (8192)
+ 1,75 (1800)
+ 12 (12288)
+ 1 (1024)
+ 12 (12288)
+ 32 (32768)
+ 32 (32768)
+ 10 (10240)
112 mb

And 48 mb are not in the mem map, so 112+48 = 160
512-160=352mb

but we have a total of 325 mb (jm8)
352-325=27 are still missing
Have a look at /proc/iomem for these 27mb yourself.

And by reading that:
http://forum.xda-developers.com/showpost.php?p=8350492&postcount=126

jpk is only missing 32 mb = gpu.

So everything is fine on the ram amount, nothing to worry about.

 

[mtoneman]

Ok I just read up on the other threads (sorry missed those initially). If I understood correctly, the radio is separate and not visible to the linux kernel (unlike the other "reserved" blocks). This probably amounts to the 48MBytes we are not seeing in the Linux dmesg output.

 

[RyanZA]

Total guess: the difference in free ram between SGS and the Tab is probably that video ram for the SGS comes out of the system ram, while the Tab probably has a dedicated framebuffer+ram for it's graphics, probably because it's required for the bigger screen.

Why does Froyo have less available ram than Eclair though (hardware is the same)? In fact, why do different Eclair versions have different available ram? Is this just tweaking, and if so, can we not tweak it ourselves?

 

[brunes]

Why does Froyo have less available ram than Eclair though (hardware is the same)? In fact, why do different Eclair versions have different available ram? Is this just tweaking, and if so, can we not tweak it ourselves?

Cause it is a different OS? With more or newer components taking various amounts of memory?

This is like saying "why does Windows 7 leave you with less available memory than Windows XP". Ummm because it is not XP.

 

[Oletros]

Cause it is a different OS? With more or newer components taking various amounts of memory?

This is like saying "why does Windows 7 leave you with less available memory than Windows XP". Ummm because it is not XP.

Mmm, and why on Nexus one there is the same RAM available in Eclair and Froyo?

And Windows 7 shows exactly the same amount of total RAM available as Windows XP.

 

[xan]

burnes,

You are wrong.

 

[RyanZA]

Cause it is a different OS? With more or newer components taking various amounts of memory?

This is like saying "why does Windows 7 leave you with less available memory than Windows XP". Ummm because it is not XP.

The 'OS' is Linux! It's always important to remember this. Android is just an ecosystem (a number of apps and services) running on top of stock linux. Just because Android has gone up a version, doesn't mean the underlying system has changed! Any changes to Android components are actually all far outside the kernel, and will use up the same ram as other userland apps.

The reserved memory has nothing to do with Android, and has everything to do with the hardware drivers. Since the hardware hasn't changed, the question is why the graphics and low level drivers have been allocated more ram in Froyo than in Eclair.

Possible explanations are that Samsung gave more ram to graphics to help with... something? Maybe OpenGL ES 2 needs more ram, and performs worse than OpenGL ES 1, and so the OpenGL ES 2 driver needs to eat up more ram now? Or the Froyo drivers might just be badly optimized. In any case, it seems like we can tweak this stuff, because Samsung can tweak it.

The question is, how do we tweak it? In the kernel video drivers? Are there open specs available that we could use to work it out? And more questions I can't think of...

 

[xan]

Well actually comparing dmesg and iomem outputs from JM8 and JPK would answer a lot of questions.

Speculating is leading us nowhere.

 

[MCOGW]

Well actually comparing dmesg and iomem outputs from JM8 and JPK would answer a lot of questions.

Speculating is leading us nowhere.

I think a very deep look at this http://opensource.samsung.com/ (and a search for "GT-I9000") would answer lots of questions (only for Eclair atm)...

 

[dcarr622]

I think a very deep look at this http://opensource.samsung.com/ (and a search for "GT-I9000") would answer lots of questions (only for Eclair atm)...

<sarcasm>Wow thanks for the link, I'm sure none of the devs on here have bothered to check!</sarcasm>