• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

RAM on the Spectrum

N

Neph81

Android Expert
OK, so I have a question that I need as many people to answer as possible. How much RAM does your Spectrum show as having.

LG Spectrum VS920 - Full phone specifications

The spec sheet says the Spectrum should have 1GB, but both mine and my gf's show 742MB. I've tried V6,V7, CM10 and all say the same thing while my Nexus 7 shows 1GB properly. If the phone got short changed, or possibly a batch of chips got mixed up, this would explain why certain people have issues while others don't.

I look forward to seeing peoples answers.
 
That's really the case with all devices... I just can't remember where I saw it documented what android uses for system process as a base. The os considers it 'unusable' ram, I believe.
 
I get what is being said, but that still makes no sense. Case in point, here are the devices I own and what they report. All come with 1GB RAM, so if the system was reserving space, I would expect it to be even, unless some how the RIL takes ups over 200MB of space.

Nexus 7 : 973MB
Ouya : 970MB
Atrix4G : 820MB
Spec : 742MB

This brings up my next question, if the system reserves space, how does it determine how much to reserve? Is this a user changeable setting such as a kernel entry?
 
But it's a point well made... LG allowed for 25% of the ram to be segregated and unusable. That's just another reason I'll never buy another LG. Poor design, planning and performance.
 
MrB206 said:
But it's a point well made... LG allowed for 25% of the ram to be segregated and unusable. That's just another reason I'll never buy another LG. Poor design, planning and performance.
Click to expand...

I wouldn't really call it unusable. I'm fairly certain that it's ram that's dedicated to your device's hardware (basically).

If you look in the kernel source code. under /lge/lge_board/i_vzw/board_i_vzw.c You'll see where it's defining out a bit of memory. I'm not going to pretend to know exactly how all this works, but if you covert all the hex out, you can probably figure out where some of the memory is being dedicated to.

#define MSM_PMEM_KERNEL_EBI1_SIZE 0x600000
#define MSM_PMEM_ADSP_SIZE 0x2000000
#define MSM_PMEM_AUDIO_SIZE 0x28B000

#define MSM_SMI_BASE 0x38000000
#define MSM_SMI_SIZE 0x4000000

#define KERNEL_SMI_BASE (MSM_SMI_BASE)
#define KERNEL_SMI_SIZE 0x600000

#define USER_SMI_BASE (KERNEL_SMI_BASE + KERNEL_SMI_SIZE)
#define USER_SMI_SIZE (MSM_SMI_SIZE - KERNEL_SMI_SIZE)
#define MSM_PMEM_SMIPOOL_SIZE USER_SMI_SIZE

#define MSM_ION_SF_SIZE 0x4000000 /* 64MB */
#define MSM_ION_CAMERA_SIZE MSM_PMEM_ADSP_SIZE
#define MSM_ION_MM_FW_SIZE 0x200000 /* (2MB) */
#define MSM_ION_MM_SIZE 0x3600000 /* (54MB) */
#define MSM_ION_MFC_SIZE SZ_8K
#ifdef IPRJ_ION_MEM_SETTING
#define MSM_ION_WB_SIZE 0x2100000 /* 33MB */
#else
#define MSM_ION_WB_SIZE 0x610000 /* 6MB */
#endif
#define MSM_ION_QSECOM_SIZE 0x600000 /* (6MB) */
#define MSM_ION_AUDIO_SIZE MSM_PMEM_AUDIO_SIZE
Click to expand...


Here's a couple converted over.

MSM SMI Base 0x38000000 (896MB)
MSM SMI Size 67108864 (64MB)
Kernel Smi Size 6291456(6MB)
PMEM Adsp Size 33554432 (32MB)
PMEM Audio Size 2666496 (2.5MB)
Click to expand...


If you were *really* so inclined to get some of the memory region back, you could possibly tweak these values collectively to see if you reclaim some of your 'unusable' ram. I can't find any documentation on what they *should* be though... at least not handily. Most likely tweaking them won't do anything but give you a kernel that won't boot.

These values are the same as stock though, so I doubt they're wrong or anything.


Personally though... The kernel is only like 16MB or so uncompressed (as far as I can tell). I could understand that size being unreported as available ram. Beyond that... It's just the rom. If it's reporting that as unavailable ram... That would be like any other OS showing all of the OS related processes as unavailable ram. Doesn't make much sense.


On to a bit of speculation!

It almost looks to me like the base for the kernel is being set at 896MB. Then it's being allotted the first 6mb that it can take up starting from there. Then the MSM_SMI_SIZE (presumably some of the stuff that lets the hardware manage itself in the following lines) gets the following 64MB (minus the 6 for the kernel, I think). Then you have the followin6g lines, which I'm guessing that MSM_ION_SF_SIZE is basically the total that the ION management can allocate out.

*896+64+64 gives you 1024.

Let's face it. It's all embedded hardware... It's going to use our ram for things like the camera, video, radios (maybe), pretty much anything and everything really. The hardware has to have *somewhere* to put it.

Now, the download for most of our current roms is around 150mb or so. Let's assume only 100 of that actually HAS to be loaded into ram for services and such. That would bring you down to 796. Let's assume the whole amount gets loaded?

746.

Not that I'm saying the entire rom gets loaded into memory. Just saying, that it counting the system partition as taking away from the ram isn't impossible. I'm sure there's other things eating that memory.

Then you start getting cached apps services etc etc etc.


Perhaps this is where your ram is going? If you're worried about the amount it's reporting... I'm sure that someone could probably work out a hack to make it report the right amount to give you a warm and fuzzy... But the ram's still going to be tied up ;)
 
Neph81 said:
Yoinx, you are quickly turning into one of my favorite devs. Keep up the good work.
Click to expand...

Whoa now. Don't go tossing that word around all willy nilly. I don't really dev. I tweak things, and build other people's code. I've done VERY little coding. Everything I've put out is either code that straight from a repo, that I compiled. Or pulls that pulled almost directly into the existing code. I am learning a bit about the source... but I'm still far from writing anything from scratch. To me, that's kinda one of the defining aspects of a dev.

IF you look through my git repo for the kernel I build for instance... everything's either a cherry-pick or a hand inserted pull (differences in the files make a straight pull impossible sometimes)... with a comment to where I got the original code from.


Hopefully though, the explanation helps you understand why you're not seeing the full amount... at least a little. Right now, I'm tweaking lowmemorykiller's settings so that it has a more aggressive OOM policy by default.

Here's a the double edged sword with that. If you're like me... I like to see available ram, which the OOM policies will do. The thing is, Android is mostly only killing *idle* processes that are in ram to clear up the ram. These processes therefore aren't really slowing anything down... So you're actually only causing yourself more lag by make the OOM policy more aggressive because the device has to use cpu cycles to kill the processes (probably not noticeable for the most part at least). Sure, if there aren't any idle ones it'll kill active ones, but meh. The reason that I like to get more aggressive on the OOM settings is

1. I like seeing free ram. That's just how I am.
2. Whether they're using CPU cycles or not, things in memory are actively in memory. The phone has to keep those memory locations "on". We're on battery... They're on. No matter how small the draw, it's a draw. Turn them off. Ya know?

The real problem is when you tweak them too high the device just starts constantly trying to kill things.
 
Fair enough, but even if it's allocated to hardware, my point is you can't use it to run apps... From a user perspective, it's 'unusable'.
 
MrB206 said:
Fair enough, but even if it's allocated to hardware, my point is you can't use it to run apps... From a user perspective, it's 'unusable'.
Click to expand...

From a user perspective the space on your internal memory that houses you boot loader, Rom, firmware, etc is also unusable storage. Nobody ever complains about it though because the phone would be useless without it taking up that space. It's the same case with the used ram. If it wasn't allocated the phone would be useless. Really. Would you rather it graphically show you that the ram is there and just used instead? ... that's the only difference.

Sent from my VS920 4G using Tapatalk 2
 
No, bit I think we can all agree 25 percent is excessive. They really should note that it takes up that much ram for hardware... If you allocate more than 10 percent of ram to hardware and process, then you're being unethical by claiming the higher ram figure. People buy a phone, as I did, with the impression a small portion of the ram is used, but the remainder is free to use... That's not the case here.
 
This is going to become my tinker project for July while work slows down. I don't expect it to actually fix anything, but it will be fun to mess around with.
 
Neph81 said:
This is going to become my tinker project for July while work slows down. I don't expect it to actually fix anything, but it will be fun to mess around with.
Click to expand...

I'm still waiting for a neph81 rom because I know it would be awesome :p
 
MrB206 said:
No, bit I think we can all agree 25 percent is excessive. They really should note that it takes up that much ram for hardware... If you allocate more than 10 percent of ram to hardware and process, then you're being unethical by claiming the higher ram figure. People buy a phone, as I did, with the impression a small portion of the ram is used, but the remainder is free to use... That's not the case here.
Click to expand...

Personally they could allocate half the ram to the hardware. It wouldn't matter. I've only seen a handful of apps that use more than 75-100 megs of ram. Android is pretty efficient Sat managing the ram so it's not like the phone using some of it matters... unless you planned on making ramdisks or something. He'll. I've never even seen android use my allocated swap space. So it's not like it's starving for ram. And I regularly have 200-300 megs free unless I've been doing a lot of multi taking... but then I just open events and tap the kill all button.

It's embedded hardware. It's not really like you're doing adb amazing amount of cad, photo design, video processing, hardcore gaming our anything else that needs that ram. Complaining that it's not available as usable ram only makes sense if you're having problems with ram.

Imo, the oom issue people are having with 1080p video now is probably because they didn't allocate MORE memory to the hardware functions. It's not complaining about user ram it's complaining that the video hardware is running out of allocated ram.

Sent from my VS920 4G using Tapatalk 2
 
Yoinx said:
Imo, the oom issue people are having with 1080p video now is probably because they didn't allocate MORE memory to the hardware functions. It's not complaining about user ram it's complaining that the video hardware is running out of allocated ram.
Click to expand...
I'm not convinced on that part. If that was the case, then my N7 should have extreme issues playing video. Here's what I see. The original firmware used a lot of software decoding to do 1080p and they had special libraries to do it. This made sense that the system then needed 25% of the ram allocated to it. But now we don't have those special libraries and in theory we should be free to mess around. As I said previously, I don't know if I will fix anything, but it will be neat to mess around with. I'm also going to have a lot of time on my hands soon and with TDM fixing almost everything else, this gives me something to do. Also, fixing video has been on my list of things to fix since CM9, so if this does work, then hell yeah.
 
Yes, android is very efficient at memory allocation, but a key factor is when our hit a memory max and it kills apps... That when we get a lag or a freeze. More ram dedicated to user use might mitigate that.
 
MrB206 said:
Yes, android is very efficient at memory allocation, but a key factor is when our hit a memory max and it kills apps... That when we get a lag or a freeze. More ram dedicated to user use might mitigate that.
Click to expand...

TBH, I think most of what you're talking about there is the REALLY conservative OOM settings that come stock in the kernel. If you haven't tweaked them, you're going to experience things like that (speculated on later).

You could try this, if you want. These are the values I'm currently using and that I'm baking into the kernel I'm tweaking (they'll be in the next one)

adb shell cat sys/module/lowmemorykiller/parameters/minfree

This will show your current minfree values (the values that are set for various things. They're set in pages, so to get mb you have to do value*4/1024 = MB.

Currently, I'm using 2048,4096,8192,16384,24576,32768

This is the note I added to the source for them so I'll just c/p:

2048, // 8MB (FOREGROUND_APP)
4096, // 16MB (VISIBLE_APP)
8192, // 32MB (SECONDARY_SERVER)
16384, // 64MB (HIDDEN_APP)
24576, // 96MB (CONTENT_PROVIDER)
32768, // 128MB (EMPTY_APP)

Basically, once you hit the value set in free ram the lowmemorykiller sill start evaluating apps to clear ram. The defaults are about half what I have set here. REALLY aggressive settings are even higher. The problem you're talking about with the ram is probably more due to the fact that the lmk is waiting so long to free memory. If your memory is low enough to trigger the lmk's default values, your system is probably under a bit of load... meaning it's a horrible time to start doing cleanup.


If you want to try these values, save your old ones somewhere... like a text document or something and just do:

You'll need to actually adb shell in... executing these from a terminal via adb shell 'command' just kept giving me permission denied...

adb root
adb shell
cd /sys/module/lowmemorykiller/parameters/
chmod 755 minfree
echo 2048,4096,8192,16384,24576,32768 > minfree
chmod 644 minfree

and you should be using the new values.


*edit*
Also, I should note that I've now started playing wtih zram and compression... just to see if I notice any improvement.
 
lg p990 smartphone has a customized kernel that can change memory size by using terminal. the max can give 64m more to the phone
 
MrB206 said:
But it's a point well made... LG allowed for 25% of the ram to be segregated and unusable. That's just another reason I'll never buy another LG. Poor design, planning and performance.
Click to expand...

The US s3 with 2gb ram only has 1.2 available to the user.

The percentage argument just doesn't cut it
 
You must log in or register to reply here.
Back
Top Bottom