Developers please help. It seems that our Nexus Ones are restricted to only 180 MB RAM as their is a bug in the kernel. Can anyone make or compile a RAMhack that can open up the extra 100-150 MB RAM. The below is an excerpt from another thread under the Nexus One - Nexus One forum here in XDA. Im wondering how much faster this thing will fly. It seems a MEMhack such as the one they used to free the 10MB for the dream might be the same approach. Apparently Google will patch this but there is no ETA on the next update.
A "memhack" kernel update in the next Nexus One OTA should give us an additional 100-150MB RAM. Who wants to try to compile a kernel that does this now?
reserved for space
flak0 said:
Developers please help. It seems that our Nexus Ones are restricted to only 180 MB RAM as their is a bug in the kernel. Can anyone make or compile a RAMhack that can open up the extra 100-150 MB RAM. The below is an excerpt from another thread under the Nexus One - Nexus One forum here in XDA. Im wondering how much faster this thing will fly. It seems a MEMhack such as the one they used to free the 10MB for the dream might be the same approach. Apparently Google will patch this but there is no ETA on the next update.
A "memhack" kernel update in the next Nexus One OTA should give us an additional 100-150MB RAM. Who wants to try to compile a kernel that does this now?
Click to expand...
Click to collapse
it's really only a matter of time on this ... once the 2.6.3x kernel is perfected for the mahimahi HW ... we'll get it. Think tank not really necessary ... as it's in the works.
~enom~
Ummmm. I thought that was the goal here:
http://forum.xda-developers.com/showthread.php?t=616383
Doubt we need the 2nd thread.
That is correct that is the goal however, until the .32 kernel is perfected is there a way to hack the current Kernel like it was done for the Dream to get the extra memory back. I am just making a suggestion. I know the only issue with the .32 kernel is the proximity sensor fails from what I have read. Can this be confirmed?
All sensors work fine with 2.6.32. Google put the sensor code in git a few days ago. I am having issues with the camera, but another person in the kernel thread said he got it working, but I can't confirm it yet.
As for the memory hack, I do not know how to do it, but the memory map and allocation are in <kernel dir>/arch/arm/mach-msm and the two files are line 959 in board-mahimahi.c and board-mahimahi.h has the memory map table breakdown.
Edit: I just got the camera working
Wont enabling that ram for program use affect the GPU(Like on the G1)?
~~Tito~~ said:
Wont enabling that ram for program use affect the GPU(Like on the G1)?
Click to expand...
Click to collapse
No, there is ram that isn't even allocated in the nexus unlike the G1. You would just move everything around and nothing would be adversely affected (in theory).
staulkor said:
No, there is ram that isn't even allocated in the nexus unlike the G1. You would just move everything around and nothing would be adversely affected (in theory).
Click to expand...
Click to collapse
Thats a bug google said would be fixed and more ram would be avail for the Nexus.
According to swetland, the only way is via the .32 kernel due to the problems caused by the 1:1 requirement. Otherwise it sounds like things go bad very quickly.
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. 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.
Click to expand...
Click to collapse
bofslime said:
According to swetland, the only way is via the .32 kernel due to the problems caused by the 1:1 requirement. Otherwise it sounds like things go bad very quickly.
Click to expand...
Click to collapse
Thanks for the details. I wasn't aware of what was causing the problem before reading this. This makes a lot of sense.
I've been playing around with my kernel lately and got caught up in researching in what actually the device reserves itself and where all that memory goes to that's not available to the user-space.
To keep things short here's a breakdown of the biggest users:
Code:
62464kB FIMC0
15360kB FIMC1
12080kB FMIC_IS
71680kB ION heap allocation for FIMC
50176kB MFC secure
4096kB MFC normal
These values are defined in the defconfig and structured into S5P device resources in mach-midas.c, device drivers being in /drivers/media/video/samsung/{mfc5x|fimc|ump} and the ION allocator in drivers/gpu/ion/.
There's several other resources out there including things like the framebuffer (only 8MB, contrary to popular belief and myth) and so on but hey are largely insignificant. The above resources eat up 202MB of reserved kernel-space alone at all times;
FMICx are the Exynos camera interface S5P device resource allocations for the camera firmwares themselves.
FMIC_IS is the memory block for the imaging subsystem.
The ION memory allocation is used by the video systems and MFC for a Video4Linux driver for playback and composition of media.
MFC is the Multi Function Codec a.k.a. the hardware decoder and encoder, this is the memory heap it uses while decoding things.
I already tried messing with the allocated spaces by reducing them and even removing them but anything less than the stock values causes the camera to crash and hardware video decoding to fail (software works without a hitch). Everything else works fine on the phone and you have 950+mB of user-space available memory instead of the 777mB we have right now.
I also tried screwing around with the memory management unit of the MFC as it seemingly had the possibility to use the subsystem used for the Mali memory through something called VCM (Virtual Contiguous Memory) but the latter part seems to be something outdated and no longer supported by the kernel and also haven't found anything newer about it since 2010. Regardless of that, it would have still been something allocated via vmalloc() and thus still residing in kernel-space.
The two possibilities I envision are:
That we somehow manage to clear up the DMA memory whenever any of the features are not used, especially the camera systems since they take up 150MB of RAM at all times.
ION is capable to have user-space CMA blocks reserved, one would have to write a user-space programm/service to detect whenever the systems are needed and allocate the memory spaces like that, and make it work.
Both are quite complex tasks, but the return on investment(effort) would be around 200MB of more usable RAM in daily operations, which is basically is a 25% boost in usable memory.
Different systems (HTC OneX I believe) already do without some of these device memory blocks (979mB user-space), although I'm not familiar on how or what they use.
This thread is meant as an idea-gathering and discussion on how to approach this and the feasibility of it, and I hope some souls can add something to it.
Andrei,I always loved your more advanced than average stuff.This is no exception.
Anyway,I just had a crazy idea.What if we could make these take up swap space?I mean,Gokhanmoral's kernel let's you create a swap file.Would it be possible to get these to take the swap space and reside there until needed?Maybe we could trick the kernel into thinking that swap is an extension of RAM and not swap or something.That would be cool.
Kernel-space memory is not swappable nor is there any magic trick to somehow circumvent this basic rule, else it would have already been done.
I found a quite nice graphic in a presentation [here] which describes the memory model:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Basically, we're dealing with the blue stuff here, if I'm not mistaken on how the S5P device handler allocates it.
Andreilux sorry disturb you but...
Looking today the app System Tuner Pro using Siyah Kernel i saw a lot configs ram related inside sysctl and buildprop tabs can you only see if any these option can help our ram problem?
Enviado do meu GT-I9300
Afaik the drivers in linux phones usually use a predetermined fixed physical address ... Without the sources i see difficult force to use userspace.
That is not true for the Android OS, as back on the Captivate, one of the best Kernel devs I know gave us like 403MB of user space in RAM when the stock value was like 337MB or something in that area. He took some of the memory from GPU, camera, and system!
b-eock said:
That is not true for the Android OS, as back on the Captivate, one of the best Kernel devs I know gave us like 403MB of user space in RAM when the stock value was like 337MB or something in that area. He took some of the memory from GPU, camera, and system!
Click to expand...
Click to collapse
It was a lot easier on the Hummingbird platform...less chance to break something
Here on the S3 platform everytime a value is changed it breaks the feature which is related at. It makes no sense theorically but maybe the hardware NEEDS that space as per firmware design.
I think the only way is to find out how the Tegra 3 plaform dynamically allocates that memory and port it over Exynos.
Sent from my GT-I9300 using Tapatalk 2
AndreiLux, this sounds absolutely amazing! Great work!
It amazes me how Samsung can have so many design wins in one product, and how many small things that don't really make a lot of sense (that our friendly devs are then tasked with fixing! )
I think it may be worth spending time on this. S3 already has solid multi-tasking once you clear out bloat ware, so I'm creaming my panties thinking what it'd be like with more ram! (I'm surprised Tegra 3 works better in this respect since most Tegra 3 phones don't have good multi tasking!)
I don't really donate to devs (apart from buying some paid versions of apps ), but if you manage to pull this off, I certainly want to 'buy you dinner'!
Good luck, everyone!
Sent from my GT-I9300 using xda premium
If you managed to pull this off it would elevate you to superstar status in this community. This would be huge for the SGS3 especially now with RAM hungry JB Rom's springing up all over the place
You would become an overnight XDA legend and deservedly so.
But.......can it be done? Over to you Andrei
New version XXDLH9 JB coming with 818mb ram now.
Samsung increase 30mb.
JB source please.
Enviado do meu GT-I9300
Andrei
There was be the same on the galaxy s1,
Some kernel makers, released a bigmem version, that breaks hd playback and camera, and one of them, was hardcore... maybe you can ask him, how they solved that on galaxy s1...
They fixed hd and camera, and all is working on the bigmem versions on the gs1...
What i would say, maybe in the gs1 section, you would get your answers...
Cheers
I'm already running at 832mB now without issues in Perseus. And to be honest I don't care what happened on the S1, what those devs did, I already did myself before I wrote this, I'm more interested in conditionally allocating these spaces which is much harder and trickier.
Funny though that LH9 has more space now... would be curious to see the changes. If it's the same, then I "wasted" a day or two of testing.
What happens in a situation where the free memory is low because of userspace processes, and the camera stuff needs to start working? Assuming no swapping mechanism is being used, of course.
Before doing the required memory allocation for FIMC, is it feasible for the kernel to synchronously invoke the LMK to make some userspace processes go away to make space in physical memory for the new kernel memory area?
AndreiLux said:
I'm already running at 832mB now without issues in Perseus. And to be honest I don't care what happened on the S1, what those devs did, I already did myself before I wrote this, I'm more interested in conditionally allocating these spaces which is much harder and trickier.
Funny though that LH9 has more space now... would be curious to see the changes. If it's the same, then I "wasted" a day or two of testing.
Click to expand...
Click to collapse
Interesting to see that Sammy, too, is going a direction to have more RAM usable, they must have noticed they just gave the device too little...
Any way to have a look behind the scences on what / how you did it to get the extra 45-50Mb RAM ? (github ?) I'd be rather keen on modding my kernel in such a way, too, until there's a way to go the whole nine yards with dynamic allocation.
I could really do with more available RAM
As for using the LMK to free up space to dynamically for the camera etc., I don't think that was the intended design of the LMK ... I don't understand anyway why Google added the LMK wrap instead of tweaking Linux OOM to take care of freeing RAM.
JP.
PS: Wow, just noticed, you're the first fellow country-man I stumble on on xda With Luxembourg beeing so small, we wouldn't happen to know each other ??
EDIT : Forget my question about GitHub, I should know better : "to first search, ask questions later"
Yank555 said:
As for using the LMK to free up space to dynamically for the camera etc., I don't think that was the intended design of the LMK ... I don't understand anyway why Google added the LMK wrap instead of tweaking Linux OOM to take care of freeing RAM.
Click to expand...
Click to collapse
When I mentioned LMK I was thinking of the mechanism in a broad sense, including OOM (I just had a look at mm/oom_kill.c which I didn't know about).
It looks like the logic is already there, but it's still required to understand whether it will kick in automatically - it looks like it's triggered automatically by pagefaults, but do these also occur on the kernel code? - if it makes a difference to have OOM sending SIGKILL instead of letting the processes be aware of termination (SIGTERM, or whatever LMK does), how can the physical areas be shifted (changing the virtual mappings) if that's important for the FIMC buffers, etc.
I guess this is already common knowledge for you guys. Don't mind me then, I'm just thinking out loud as this is new to me
Tungstwenty said:
When I mentioned LMK I was thinking of the mechanism in a broad sense, including OOM (I just had a look at mm/oom_kill.c which I didn't know about).
It looks like the logic is already there, but it's still required to understand whether it will kick in automatically - it looks like it's triggered automatically by pagefaults, but do these also occur on the kernel code? - if it makes a difference to have OOM sending SIGKILL instead of letting the processes be aware of termination (SIGTERM, or whatever LMK does), how can the physical areas be shifted (changing the virtual mappings) if that's important for the FIMC buffers, etc.
I guess this is already common knowledge for you guys. Don't mind me then, I'm just thinking out loud as this is new to me
Click to expand...
Click to collapse
I'm just getting into this, too
We had a memory issue on a kernel on Sensation, which is why I've been digging a little into this stuff in the last few days / weeks
I've not gotten to try to understand the fundamental difference between OOM and LMK, just noticed what may be one of the fundamental differences, LMK considers cache memory blocks to be free, and even though I've not checked OOM, I'd think it's not the same for Linux OOM.
But I'll stop here, I think we're maybe drifting away from the topic
If pagefaults trigger OOM mechanisms, or free memory dropping below a threshold for LMK, it should be possible to trigger those when for example the camera driver is needed.
Maybe upping the LMK limits above the size of what is needed could do as well, as those would have LMK kick in, thus freeing RAM to at least that level ...
On the other hand I suppose what will be needed here is a big contiguous memory area, so freeing RAM alone wouldn't be enough if it's fragmented, a memory compactation would need to be triggered as well to ensure a sufficiantly sized bontiguous area of memory becomes available...
JP.
EDIT: Just thought of another detail, if kernel memory and userspace memory are two big contiguous memory areas (don't know this), the freed block whould need to be in the userspace block at the boundary of the kernel space block ? Since we would have to move that boundary ... to get userspace to kernel space ?
@ andrei and other experts here
Wanted to know something, as samsung has increased the free memory from 778 mb to 818 mb(40 mb higher) its clear that the additional 40 mb has been released from FMIC,ION,MFC blocks. my query is what impact it would have on the functionality of these blocks? also as samsung has done it officially in their rom it can be considered that there may be no impact but why did samsung didnt do it in the first place?
bala_gamer said:
@ andrei and other experts here
Wanted to know something, as samsung has increased the free memory from 778 mb to 818 mb(40 mb higher) its clear that the additional 40 mb has been released from FMIC,ION,MFC blocks. my query is what impact it would have on the functionality of these blocks?
Click to expand...
Click to collapse
If it was possible to look at their changes (sources) ... But the impact shouldn't be big / noticeable, else I doubt they would have done it...
JP.
Yank555 said:
Maybe upping the LMK limits above the size of what is needed could do as well, as those would have LMK kick in, thus freeing RAM to at least that level ...
Click to expand...
Click to collapse
True, but in practice that would be the equivalent of having less free memory because for all purposes the OS would start killing processes earlier, right?
So we need to keep a lighter limit on LMK (for RAM to actually be used for multiple open processes), but still be able to trigger it synchronously when RAM needs to be "reduced" to make space for the kernel memory for FIMC / whatever.
Yank555 said:
On the other hand I suppose what will be needed here is a big contiguous memory area, so freeing RAM alone wouldn't be enough if it's fragmented, a memory compactation would need to be triggered as well to ensure a sufficiantly sized bontiguous area of memory becomes available...
JP.
EDIT: Just thought of another detail, if kernel memory and userspace memory are two big contiguous memory areas (don't know this), the freed block whould need to be in the userspace block at the boundary of the kernel space block ? Since we would have to move that boundary ... to get userspace to kernel space ?
Click to expand...
Click to collapse
About it being continuous and/or needing to be on the boundary, that's exactly my point about whether virtual address remapping is required or not. Virtual remapping might be enough, bit it could also be the case that physical map needs to be compacted or reordered, and virtual mapping be fixed so all pointers keep working as before.
bala_gamer said:
@ andrei and other experts here
Wanted to know something, as samsung has increased the free memory from 778 mb to 818 mb(40 mb higher) its clear that the additional 40 mb has been released from FMIC,ION,MFC blocks. my query is what impact it would have on the functionality of these blocks? also as samsung has done it officially in their rom it can be considered that there may be no impact but why did samsung didnt do it in the first place?
Click to expand...
Click to collapse
As far as I can see, no effects outside of extreme conditions. You'll be able to test it yourselves soon.
So, using extweaks I see that theres a zram setting thats default is off. I have a couple questions about it. To my understanding, enabling it adds more usable ram for the android system, but it uses cpu to compress it right? So does this mean that it uses more battery life as well? or by adding more ram, will it save battery life because its not having to reorganize system resources all the time. I don't quite understand how it works.
someone enlighten me. My main question is, does it negatively or positively impact battery performance.
thanks
I don't know much about how it works, but I can tell you when I tried to use it it slowed down my system. No positive effects noticed.
aspen1135 said:
So, using extweaks I see that theres a zram setting thats default is off. I have a couple questions about it. To my understanding, enabling it adds more usable ram for the android system, but it uses cpu to compress it right? So does this mean that it uses more battery life as well? or by adding more ram, will it save battery life because its not having to reorganize system resources all the time. I don't quite understand how it works.
someone enlighten me. My main question is, does it negatively or positively impact battery performance.
thanks
Click to expand...
Click to collapse
More cpu work load = more battery drain , so yes theoretically zram will decrease your battery life but i don't have numbers to prove it . Also your kernel must support zram to use it . I haven't seen a huge performance increase or the like enabling it but multitasking seems more smooth or so it feels to me .
leap before you think
So has anyone tried swap on this device?
I was thinking that we might be able to increase ram operation if there was a swap partition.
I'm not exactly sure if it will work....
If anyone see's this thread and has a class 10 micro sd card and they want to try it please let me know how it affects the benchmarking results.
(I'd do it, but I have a crappy class 4)
Darin_Ram said:
So has anyone tried swap on this device?
I was thinking that we might be able to increase ram operation if there was a swap partition.
I'm not exactly sure if it will work....
If anyone see's this thread and has a class 10 micro sd card and they want to try it please let me know how it affects the benchmarking results.
(I'd do it, but I have a crappy class 4)
Click to expand...
Click to collapse
I tried using swap for awhile on my old HD2 which only had .5gb, but not here. The question I have to ask is why? In most of the current ROMs developers have already added scripts that kill dormant processes to free up real memory. Even when I've got a dozen apps open I've got plenty of RAM available. What kind of out of memory issues are you experiencing where you think swap would help?
Odysseus1962 said:
I tried using swap for awhile on my old HD2 which only had .5gb, but not here. The question I have to ask is why? In most of the current ROMs developers have already added scripts that kill dormant processes to free up real memory. Even when I've got a dozen apps open I've got plenty of RAM available. What kind of out of memory issues are you experiencing where you think swap would help?
Click to expand...
Click to collapse
Well it's not exactly a out of memory problem. I just wanted to see if the performance would be affected if a linux swap partition for ram would increase or decrease the ram operation.
I know we don't have the most high end device out there, but the specs are supposed to be better than an S2, yet it surpasses ours. It has a slower processor and less 3d graphics than the amaze and still it beats it.
Ram operation on the S2 according to Antutu: 705
Ram operation on the Amaze according to Antutu: 356
That's about half!!!!!
And I'm pretty sure if we found a way to increase the ram operation it'd help with all the other results.
I don't know why this is the case, but probably has more to do with the software running on the devices than the components. Sense is a lot of things most of which are good, but one thing for sure is it's s resource hog.
Odysseus1962 said:
I don't know why this is the case, but probably has more to do with the software running on the devices than the components. Sense is a lot of things most of which are good, but one thing for sure is it's s resource hog.
Click to expand...
Click to collapse
I believe my rom is senseless, cause I'm on the Xperia Z Ultra by shubham211995