Related
In general:
The problem with app2SD, in general, is slow SD card speeds.
Solution:
Hybrid storage pools, using the inbuilt applicaiton directory as the cache and the microSD directory as the main storage.
blogs.sun.com/ahl/entry/shadow_of_hsp explains some of the conceptual stuff
Issues:
ZFS is only available via FUSE
...
Thoughts?
.milFox said:
In general:
The problem with app2SD, in general, is slow SD card speeds.
Solution:
Hybrid storage pools, using the inbuilt applicaiton directory as the cache and the microSD directory as the main storage.
blogs.sun.com/ahl/entry/shadow_of_hsp explains some of the conceptual stuff
Issues:
ZFS is only available via FUSE
...
Thoughts?
Click to expand...
Click to collapse
While I think having snapshot, replication, 100% consistency, and dedup capability would be the coolest thing on a phone, I think the ZIL would burn up the sd quicker and the resource utilization would eat battery and memory for the transactional caches to make it practical
.milFox said:
In general:
The problem with app2SD, in general, is slow SD card speeds.
Solution:
Hybrid storage pools, using the inbuilt applicaiton directory as the cache and the microSD directory as the main storage.
blogs.sun.com/ahl/entry/shadow_of_hsp explains some of the conceptual stuff
Issues:
ZFS is only available via FUSE
...
Thoughts?
Click to expand...
Click to collapse
My only thought is: "why?". I have every app I want installed and still have 102MB available. Given just how much more memory this has than the G1's of yore, I don't really see much of a reason for AppstoSD, especially since Google is releasing their own implementation *soon*.
I was already down to 29 Meg on my internal memory.
I'll be happy when Google implements a2sd. I can't see it being any different than what a2sd us doing though.
Just make sure you have a class 6 card.
Down to fairly minimal memory as well, here.
as to 'why' over conventional a2sd ... the in-built memory is faster than even a class 6 card. A hybrid zpool will allow the faster memory to cache the slower memory (normally, a hybrid zpool combines a SSD with a hard drive pool).
Ah, didn't realize people were having problems with it. Even so, Google has announced that they're working on it themselves and since it will be an actual part of the Android OS, rather than something hacked on, I imagine it'll be a better implementation that whatever we can do. I'll be waiting for that up and coming android release.
People who are running out of memory have way too many apps installed.
Anyway, I think you will find it very difficult to use the MTD block for this purpose.
miketaylor00 said:
People who are running out of memory have way too many apps installed.
Click to expand...
Click to collapse
I disagree, I only have 50 apps in total but have used 107Mb of my 196Mb used.
I lost 33Mb just flashing a theme.
Does anyone know if TA utility will work on the Nexus to move all the Caches?
Which memory are we talking about, primary or storage memory? If memory serves me correctly, the current os can only 256MB of primary memory but that will be increased to the full 512 in a later OTA update. I thought I saw some thread flying around here about that.
Amdathlonuk said:
I disagree, I only have 50 apps in total but have used 107Mb of my 196Mb used.
I lost 33Mb just flashing a theme.
Does anyone know if TA utility will work on the Nexus to move all the Caches?
Click to expand...
Click to collapse
You almost proved his point. 33MB is a ****ty size for a theme - get a better Themerto follow. Hell, most themes for Windows aren't that big.
-bZj
miketaylor00 said:
People who are running out of memory have way too many apps installed.
Anyway, I think you will find it very difficult to use the MTD block for this purpose.
Click to expand...
Click to collapse
How on earth can you possibly make this judgment? Have you ever hear of cache? What about app data? Not to tout my own app (see sig), but the reason I created it was because my myTouch, with all of its storage, would run very low the regular basis. Besides, I like to download apps, both free and paid. Why should I be limited? Personally, I never even came close to filling up my 500MB ext partition on my myTouch but could easily have 50-100MB of cache in just a few days. I think having a GB of internal would suffice. It would allow me to comfortably add as many apps as I please and at the same time, not think about cache and data on the daily basis. $575 and I'm still going to have to hack a2sd on to this. I hate that. I'd much rather use internal storage.
Personally, I'm all for it. If nothing else, it would be one hell of a proof of concept and would likely be useful especially to those who like to run their devices lean and fast. There are too many nice things to say about ZFS, so I'll just say this: it's only a matter of time and what better time than now?
But I don't think it would happen, for the same reason ZFS hasn't been ported to linux, incompatible licenses.
http://zfs-fuse.net/
Can we get the ball rolling on this?
dont worry boys
A king nexus build is coming VERY soon with OPTIONAL a2sd and kingnexus kernel #1
SOON!
kingklick said:
dont worry boys
A king nexus build is coming VERY soon with OPTIONAL a2sd and kingnexus kernel #1
SOON!
Click to expand...
Click to collapse
So what's the Kingnexus kernel have?
cyanogen said:
So what's the Kingnexus kernel have?
Click to expand...
Click to collapse
+1 .... and how does it relate to ZFS (y on earth) and apps2sd?
~enom~
lmao you pissed of cyanogen ! xD
miketaylor00 said:
People who are running out of memory have way too many apps installed.
Anyway, I think you will find it very difficult to use the MTD block for this purpose.
Click to expand...
Click to collapse
Ever hear of games? Seriously, making a statement like this is just plain ridiculous. Homerun Battle 3D is over 30MB in and of itself. Yes, believe it or not, people actually use their nearly $600 3.7" screen for something other than reading email, of which I do plenty. So yes, I hacked apps2sd onto my Cyan ROM and it runs beautifully. I can't even tell the difference between this and internal it's so smooth. By the time Google releases a viable apps2sd the N1 will be yesterday's news. Internal storage and capacitive buttons = fail on the N1. Otherwise, kick ass device.
I never touched the kernal on alpha7 just added a s.d>placeholder in system int.d folder got apps2sd and the rest was set. Did not know kernal was part.
Hope the kernal is good.
I'm currently running the devil kernel on my phone, using the new devil app to control settings but I really don't know a couple settings though. First what I'd zram and is it better than swap? And what's the best value to set the zram at? I have it on 150mb.
Also what's better zram or swap?
Dude look @ the op
Sent from my SGH-T959 using Tapatalk 2
No info about what it is in the op U_U
well, based on my reading...(Basically meaning take this with a grain of salt because I may not perfectly re-present the information, but this is how I've come to understand it lol )
zram basically compresses unused apps within the system RAM. This allows the system to swap less needed processes to the zram partition for faster access at a later time, instead of killing them. This does take up some of your ram though, so I imagine that the value you are setting is determining exactly what percentage of your ram that the zram partition is allotted.
Swap instead uses a small portion of the SDcard like RAM. The phone will attempt to keep as much within the ram as possible until fill, and then begin using the swap partition on the SDcard. At that point, the phone will begin moving inactive blocks of memory to the SD, freeing up RAM for active processes. If one of the pages on the SD needs to be accessed again, it will be moved back into RAM, and a different inactive page in RAM will be moved onto the SD ('swapped').
Swap files don't restrict available RAM but writing to the sdcard impacts the speed of opening apps.
Now, which is better? No idea ^^ Lol
Holly crap I'm enabling swap lol. Do I need to repartition my SD card for swap?
I wouldn't enable swap, you don't need it, zram us nifty but also not need. Your system can handle memory just fine without you. Just let it to its thing and you will be fine.
Sent from my Galaxy Nexus using Tapatalk 2
I agree completely. My former device had a hack that we came up with that would force app2sd on a 2.1 build. This was great at the time but it cause some serious lag. We then enabled the swap to help with the memory issues. It worked for awhile but then all these apps started to come out that were, not to sound funny, memory hogs. This device only had 128mb of user RAM, so it was a constant struggle to get it working. Gotta remember that this was pre-GB times, so Froyo was the ICS of that time.
Here is more to read from this devices section about how swap works. The thread was revived on Post #9 and my explaination is Post#16.
Moral of the story is that I agree with Eco, let the phone work for you and not you against it. There are few memory issues with the Vibrant. Is it running 2gb of RAM? No but do you really need something like that on a phone?
Woodrube said:
I agree completely. My former device had a hack that we came up with that would force app2sd on a 2.1 build. This was great at the time but it cause some serious lag. We then enabled the swap to help with the memory issues. It worked for awhile but then all these apps started to come out that were, not to sound funny, memory hogs. This device only had 128mb of user RAM, so it was a constant struggle to get it working. Gotta remember that this was pre-GB times, so Froyo was the ICS of that time.
Here is more to read from this devices section about how swap works. The thread was revived on Post #9 and my explaination is Post#16.
Moral of the story is that I agree with Eco, let the phone work for you and not you against it. There are few memory issues with the Vibrant. Is it running 2gb of RAM? No but do you really need something like that on a phone?
Click to expand...
Click to collapse
Exactly, Android is designed for low Memory systems. It can handle out of Memory situations on its own, and will kill unneeded apps as is necessary to free ram for running apps. Don't worry about how much "free" ram you have because it doesn't matter. You want more free ram learn to set the ram usage settings to be more aggressive at killing idle apps. It'll and up using more battery, but if free ram is what you want then that's how to do it.
Sent from my Galaxy Nexus using Tapatalk 2
Woody said:
I agree completely. My former device had a hack that we came up with that would force app2sd on a 2.1 build. This was great at the time but it cause some serious lag. We then enabled the swap to help with the memory issues. It worked for awhile but then all these apps started to come out that were, not to sound funny, memory hogs. This device only had 128mb of user RAM, so it was a constant struggle to get it working. Gotta remember that this was pre-GB times, so Froyo was the ICS of that time.
Here is more to read from this devices section about how swap works. The thread was revived on Post #9 and my explaination is Post#16.
Moral of the story is that I agree with Eco, let the phone work for you and not you against it. There are few memory issues with the Vibrant. Is it running 2gb of RAM? No but do you really need something like that on a phone?
Click to expand...
Click to collapse
Good old g1 and mytouch days
No signature for you!
Woody said:
There are few memory issues with the Vibrant. Is it running 2gb of RAM? No but do you really need something like that on a phone?
Click to expand...
Click to collapse
Actually, yes. There are certain apps, like Facebook, Whatsapp, Skype and probably more, that have their background services running even if you close the app. Those services are for sending notification, but they are slowing down this device very much (Even if only the Facebook service is running). So I do feel the device does not handle memory so good. And I can't blame it, since it has a limited memory, but I do wish I had more RAM.
Don't enable zram or swap unless you have the EU bug or like your shizz lag like a mo'fo'. If your phone is playing nicely, then disable both. Allow Purging of Assets also.Set it to two processes in Dev Section.
Sent from a Beaner
Like the SIG D'fresh!
Sent from my SCH-I535 using xda premium
Dougfresh said:
... Set it to two processes in Dev Section.
Sent from a Beaner
Click to expand...
Click to collapse
By this do you mean the "Background Process Limits"?
Sent from my SGH-T959 using xda app-developers app
scottPilgrim said:
hey devil, got a question for you...
any particular reason why you removed zRAM from your kernel? i was wondering if you could elaborate a little bit on why it isn't necessary on this device.
Thanks man
Click to expand...
Click to collapse
Xenoism said:
zram basically compresses unused apps within the system RAM. This allows the system to swap less needed processes to the zram partition for faster access at a later time, instead of killing them. This does take up some of your ram though, so I imagine that the value you are setting is determining exactly what percentage of your ram that the zram partition is allotted.
Click to expand...
Click to collapse
Not really needed on our device that have 2gb of ram memory.
Have ever been in a situation where you have been out of free ram? Neither have I.
Sent from my GT-N7100 using Tapatalk 2
Our devices don't have 2gb ram memory. They have 512mb ram memory
Sent from my SGH-T959 using xda app-developers app
cannondaleV2000 said:
Our devices don't have 2gb ram memory. They have 512mb ram memory
Sent from my SGH-T959 using xda app-developers app
Click to expand...
Click to collapse
1+
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 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
We hate zram. This easy mod will disable it on the stock Moto G4 rom. In our experiences with disabling zram we've been able to notice performance gains on devices from 1-3gb of ram (Moto E 2015, Moto G 2014, Honor 5X, Huawei GX8).
8/13/16 Update: Now flashable via TWRP.
1. Have TWRP and MAKE A NANDROID BACKUP BEFORE YOU DO ANYTHING. I am not responsible if you break your phone. If you don't already know how to restore your device to the way it was when you bought it, do not do any of this.
2. Flash via TWRP:
Zram Off: https://www.androidfilehost.com/?fid=24588232905722629
To return to stock (I cannot promise this is exactly the same as the G4 Plus. If any G4 Plus users want to send me a hastebin of the /system/etc/init.qcom.zram.sh file to compare that would help).
Zram On: https://www.androidfilehost.com/?fid=24588232905722630
Old instructions if you prefer to do it manually:
1. Be rooted.
2. Have a stock nandroid backup.
3. Backup /system/etc/init.qcom.zram.sh to some safe place.
4. Unzip MotoG4_Zram_Disable
5. Using root file manager of your choice (I like Solid Explorer) copy init.qcom.zram.sh to /system/etc folder and overwrite the existing file.
This has been tested working on the XT1625 and likely works on the G4 Plus as well. If this works for you on a different variant, please leave a reply and I'll do my best to update this post.
Links:
Disable Zram: https://www.androidfilehost.com/?fid=24588232905722479
If for some unholy reason you'd like to turn it back on, follow the same process copying your backed up init.qcom.ram.sh file back to /system/etc.
Thanks to @EarlyMon for his edits that allow us to keep zram disabled without having to run terminal commands at every boot.
Wouldn't it be easier to use something like EX kernel manager. Thank you for your hard work though
khaoticking said:
Wouldn't it be easier to use something like EX kernel manager. Thank you for your hard work though
Click to expand...
Click to collapse
I did use kernel adiutor, but zram support has been removed. Can't speak to EX kernel manager. However, the one advantage is that it boots with it turned off. Either solution would work, but this should be faster and possibly one less app you have to install if you're OCD about how many apps you have on your phone.
Very true and ex kernel manager does support it still and @flar2 does great work keeping the app updated
Confirmed working on my 4gb ram g4 plus.
What is the purpose of ZRam feature?
Sent from my XT687 using xda premium
---------- Post added at 01:06 AM ---------- Previous post was at 01:04 AM ----------
If you gain performance without this, it sounds like foot of brake by the manufacturers, NOH?
Sent from my XT687 using xda premium
fix-this! said:
Confirmed working on my 4gb ram g4 plus.
Click to expand...
Click to collapse
Thanks for sharing your result!
Dethfull said:
What is the purpose of ZRam feature?
Click to expand...
Click to collapse
Zram is virtual ram to give low ram devices more available ram by using a partition on the nand. Essentially you have info moving from ram to the nand and in the background you have constant zipping and unzipping process running as this information is being moved around. We believe it leads to lag (ever need to reboot because the phone starts slowing down?) and crappy performance as well as additional, unnecessary wear and tear on your nand. Android manages ram just fine without zram. @EarlyMon could do a much better explanation, but this is the over simplified version as I understand it.
See this for a better explanation: http://forum.xda-developers.com/showpost.php?p=65156077&postcount=6
redbeard1083 said:
Zram is virtual ram to give low ram devices more available ram by using a partition on the nand. Essentially you have info moving from ram to the nand and in the background you have constant zipping and unzipping process running as this information is being moved around. We believe it leads to lag (ever need to reboot because the phone starts slowing down?) and crappy performance as well as additional, unnecessary wear and tear on your nand. Android manages ram just fine without zram. @EarlyMon could do a much better explanation, but this is the over simplified version as I understand it.
Click to expand...
Click to collapse
I was under the impression that it was virtually the opposite of your explanation...
Z ram uses a compressed "ram disk" for paging BEFORE hitting the nand memory... to not only help in speeds of retrieval but to keep nand write to a minimum (since solid state storage only has a finite amount of write cycles). The lag comes from having to "unzip" the info from the ram disk before use when switching between apps. (this takes some CPU power and obviously a bit of lag can be seen sometimes). However, zram is there to help by giving a use for unused ram when not in use as well as keeping unnecessary writes from hitting the nand.
If a app requires the memory currently in use by zram, the linux kernel will unload the data to the disk (or ssd / nand) and recall the info as a normal page file when needed to free up the ram when necessary.
Before and after, results on AnTuTu. Not a big difference, but I have to admit, the phone does seem to run smoother.
MadGoat said:
I was under the impression that it was virtually the opposite of your explanation...
Z ram uses a compressed "ram disk" for paging BEFORE hitting the nand memory... to not only help in speeds of retrieval but to keep nand write to a minimum (since solid state storage only has a finite amount of write cycles). The lag comes from having to "unzip" the info from the ram disk before use when switching between apps. (this takes some CPU power and obviously a bit of lag can be seen sometimes). However, zram is there to help by giving a use for unused ram when not in use as well as keeping unnecessary writes from hitting the nand.
If a app requires the memory currently in use by zram, the linux kernel will unload the data to the disk (or ssd / nand) and recall the info as a normal page file when needed to free up the ram when necessary.
Click to expand...
Click to collapse
Here's a better explanation of what we're doing. From the Honor 5X forum: http://forum.xda-developers.com/showpost.php?p=65156077&postcount=6
NexusFan9219 said:
Before and after, results on AnTuTu. Not a big difference, but I have to admit, the phone does seem to run smoother.
Click to expand...
Click to collapse
We've had some trouble nailing down significant performance gains on other devices using benchmarking tools, but yeah I would agree that the user experience is smoother.
MadGoat said:
I was under the impression that it was virtually the opposite of your explanation...
Z ram uses a compressed "ram disk" for paging BEFORE hitting the nand memory... to not only help in speeds of retrieval but to keep nand write to a minimum (since solid state storage only has a finite amount of write cycles). The lag comes from having to "unzip" the info from the ram disk before use when switching between apps. (this takes some CPU power and obviously a bit of lag can be seen sometimes). However, zram is there to help by giving a use for unused ram when not in use as well as keeping unnecessary writes from hitting the nand.
If a app requires the memory currently in use by zram, the linux kernel will unload the data to the disk (or ssd / nand) and recall the info as a normal page file when needed to free up the ram when necessary.
Click to expand...
Click to collapse
Hi.
You're correct about zram overall up to the point that it helps by giving use for unused ram.
Let's clarify for everyone's sake.
Swap is virtual memory strategy to augment available RAM.
It first appeared for most people on desktops using a portion of the hard drive to emulate RAM, and (simplified version) swapped the contents of RAM with the local storage set aside for that, back and forth as needed - to assist with better overall multitasking, and for that it worked a treat. (It actually first appeared on mainframes and then minicomputers for those with OCD.)
Android is a real-time Linux implementation and Linux has virtual memory strategies including swap as part of its mainframe heritage.
2010 saw the rise of the superphones with an astonishing 512 MB of RAM on board - with most Androids having far less - and then take away some for hardware functions, then the operating system, and what was left was yours for apps.
I've been using Android since 2009 and I don't remember who started it or when, but by the summer of 2010, adding swap to an Android by repartitioning the SD card and exploiting that the kernel already knew how to use it for swap if done right had become a darling mod.
Eventually phones got enough ram to outgrow it (and while popular with many, the mod was never universally accepted as the right thing to do) but manufacturers kept producing cheap phones without sufficient hardware resources (still do, sadly) and so the mod never actually died gracefully.
And let's stay in the real world - Android is a compact, real-time Linux - it's not a desktop Linux distribution and it was specifically designed for mobile use.
Enter the Dalvik virtual machine, the cornerstone that makes Android different from a desktop, and it's post-KitKat replacement, the Android Runtime.
Either way, let's call that the Android machine.
And what it does is provide the app environment with the job control and RAM management for apps within a closed system, above the kernel, and it does everything you need for shuffling apps around and optimizing your multitasking experience.
It doesn't need any help, all things being proper.
But things aren't always proper and starved phones continue to be made.
Enter Qualcomm.
They provided a shell script to add swap back on for phones choking with less than 1 GB of RAM on board in hardware.
It's in /system/etc/init.qcom.zram.sh on your new Moto and it's what I provided the patch for.
Initially, it tested to see if a phone had less than 1 GB RAM and do nothing if 1 GB or larger, otherwise, set up and launch zram.
And all zram is is a set aside in RAM that's used for swap through the magic of compression and decompression to try to get the appearance of more RAM.
This sounded so great on paper that this travesty has been adopted by flagships and the Nexus and Google has even codified it for manufacturers with what they consider to be appropriate guidelines for implementation.
Frankly, it's change for change's sake by developers who have no full grasp of the history of Android swap and live in a theoretical world without looking at what it really does to user performance in the face of a larger Android needing more RAM in the first place, on less than ideal mobile processors.
Android already does multitasking management without giving the processor a redundancy with compression and decompression lying to it about available RAM and it's highly optimized after years of ongoing refinement.
Zram is a moving target that fails often (Nexus 6P owners who don't get rid of it like to reboot their phones every few days to restore speed, something not needed by people who have taken the cure, thanks to entropy with zram processing) and manufacturers think that this lipstick will look even more red on the pig if they increase the compression ratio.
Stealing CPU resources that you need a lot more than you need RAM.
Go ahead and look in /system/etc/init.qcom.zram.sh on your Moto - please don't take my word for it.
Moto has followed in the new Chinese tradition of changing what that file does, ignoring that Qualcomm said in the comments, in plain English, to only do this for phones without enough RAM.
The Moto doesn't qualify and doesn't need it by design.
You can also see that all it does is call the toybox command to turn it off right after boot, at the end of initialization.
I left the original Moto contents in place because the OP asked late at night for some help when Kernel Adiutor took the turn-off feature away and I never got back to help with something that looked prettier. (And nothing bad on Kernel Adiutor, zram implementation and proliferation is getting to be a burden for maintenance, I don't blame them.)
Past the comments, Moto did not leave the original Qualcomm code in place.
The canonically correct no-swap fix for your phone would be to go in to the ramdisk in the boot image and remove where it gets turned on in the first place.
And then have to redo the mod every time Moto updates that.
Ain't nobody got time for that, and I don't own this phone, I'm helping friends solve this problem with the easy button.
My method leaves the zram declaration in place (you can see it in /proc/partitions) but it's harmlessly unused after the mod.
To learn more about the state of your memory and get some simple explanations without all the voodoo, check out "RAM Truth"
https://play.google.com/store/apps/details?id=sa.ramtruth
It doesn't spy on you, it has no ads or tricky revenue games, it's something that two of us provided as a labor of love for the Android community because after a lot of years, we were repeating the same answers to the same questions.
Knowledge is power ok.
And if you disagree with me about how zram sucks and needs to have a stake driven through its heart, flash the bit that restores your phone to the way it was when you got it and enjoy it in good health. About one in a thousand go that way and that's fine. No need for debate.
Android is all about choice.
Hope this clarifies, thanks for reading, sorry for typos, this was all just flow of consciousness without editing.
EarlyMon said:
Hi.
You're correct about zram overall up to the point that it helps by giving use for unused ram.
Let's clarify for everyone's sake.
Swap is virtual memory strategy to augment available RAM.
It first appeared for most people on desktops using a portion of the hard drive to emulate RAM, and (simplified version) swapped the contents of RAM with the local storage set aside for that, back and forth as needed - to assist with better overall multitasking, and for that it worked a treat. (It actually first appeared on mainframes and then minicomputers for those with OCD.)
Android is a real-time Linux implementation and Linux has virtual memory strategies including swap as part of its mainframe heritage.
2010 saw the rise of the superphones with an astonishing 512 MB of RAM on board - with most Androids having far less - and then take away some for hardware functions, then the operating system, and what was left was yours for apps.
I've been using Android since 2009 and I don't remember who started it or when, but by the summer of 2010, adding swap to an Android by repartitioning the SD card and exploiting that the kernel already knew how to use it for swap if done right had become a darling mod.
Eventually phones got enough ram to outgrow it (and while popular with many, the mod was never universally accepted as the right thing to do) but manufacturers kept producing cheap phones without sufficient hardware resources (still do, sadly) and so the mod never actually died gracefully.
And let's stay in the real world - Android is a compact, real-time Linux - it's not a desktop Linux distribution and it was specifically designed for mobile use.
Enter the Dalvik virtual machine, the cornerstone that makes Android different from a desktop, and it's post-KitKat replacement, the Android Runtime.
Either way, let's call that the Android machine.
And what it does is provide the app environment with the job control and RAM management for apps within a closed system, above the kernel, and it does everything you need for shuffling apps around and optimizing your multitasking experience.
It doesn't need any help, all things being proper.
But things aren't always proper and starved phones continue to be made.
Enter Qualcomm.
They provided a shell script to add swap back on for phones choking with less than 1 GB of RAM on board in hardware.
It's in /system/etc/init.qcom.zram.sh on your new Moto and it's what I provided the patch for.
Initially, it tested to see if a phone had less than 1 GB RAM and do nothing if 1 GB or larger, otherwise, set up and launch zram.
And all zram is is a set aside in RAM that's used for swap through the magic of compression and decompression to try to get the appearance of more RAM.
This sounded so great on paper that this travesty has been adopted by flagships and the Nexus and Google has even codified it for manufacturers with what they consider to be appropriate guidelines for implementation.
Frankly, it's change for change's sake by developers who have no full grasp of the history of Android swap and live in a theoretical world without looking at what it really does to user performance in the face of a larger Android needing more RAM in the first place, on less than ideal mobile processors.
Android already does multitasking management without giving the processor a redundancy with compression and decompression lying to it about available RAM and it's highly optimized after years of ongoing refinement.
Zram is a moving target that fails often (Nexus 6P owners who don't get rid of it like to reboot their phones every few days to restore speed, something not needed by people who have taken the cure, thanks to entropy with zram processing) and manufacturers think that this lipstick will look even more red on the pig if they increase the compression ratio.
Stealing CPU resources that you need a lot more than you need RAM.
Go ahead and look in /system/etc/init.qcom.zram.sh on your Moto - please don't take my word for it.
Moto has followed in the new Chinese tradition of changing what that file does, ignoring that Qualcomm said in the comments, in plain English, to only do this for phones without enough RAM.
The Moto doesn't qualify and doesn't need it by design.
You can also see that all it does is call the toybox command to turn it off right after boot, at the end of initialization.
I left the original Moto contents in place because the OP asked late at night for some help when Kernel Adiutor took the turn-off feature away and I never got back to help with something that looked prettier. (And nothing bad on Kernel Adiutor, zram implementation and proliferation is getting to be a burden for maintenance, I don't blame them.)
Past the comments, Moto did not leave the original Qualcomm code in place.
The canonically correct no-swap fix for your phone would be to go in to the ramdisk in the boot image and remove where it gets turned on in the first place.
And then have to redo the mod every time Moto updates that.
Ain't nobody got time for that, and I don't own this phone, I'm helping friends solve this problem with the easy button.
My method leaves the zram declaration in place (you can see it in /proc/partitions) but it's harmlessly unused after the mod.
To learn more about the state of your memory and get some simple explanations without all the voodoo, check out "RAM Truth"
https://play.google.com/store/apps/details?id=sa.ramtruth
It doesn't spy on you, it has no ads or tricky revenue games, it's something that two of us provided as a labor of love for the Android community because after a lot of years, we were repeating the same answers to the same questions.
Knowledge is power ok.
And if you disagree with me about how zram sucks and needs to have a stake driven through its heart, flash the bit that restores your phone to the way it was when you got it and enjoy it in good health. About one in a thousand go that way and that's fine. No need for debate.
Android is all about choice.
Hope this clarifies, thanks for reading, sorry for typos, this was all just flow of consciousness without editing.
Click to expand...
Click to collapse
Wow,
Ok, so next question...
How do you modify the zram partition size?
MadGoat said:
Wow,
Ok, so next question...
How do you modify the zram partition size?
Click to expand...
Click to collapse
You may find an app that will help you with that or you're going to have to modify the ramdisk.
Good luck improving performance. It's not going to happen but good luck, the exercise will probably be revealing.
EarlyMon said:
You may find an app that will help you with that or you're going to have to modify the ramdisk.
Good luck improving performance. It's not going to happen but good luck, the exercise will probably be revealing.
Click to expand...
Click to collapse
Fully understand the performance impacts zram has now... And thank you for the explanation!
I however only have 2gb on this phone and zram has shown to be utilized to about 300 MB. However the zram partition is set at 512mb. It's like to play with 256 or 384 if I can. Ex manager allows zram partition sizes, however I would rather permanently change instead of an "after boot" tweak...
I see in the aforementioned file:
setprop ro.config.zram true
#Set per_process_reclaim tuning parameters
# BEGIN Motorola,IKSWM-36235
#echo 1 > /sys/module/process_reclaim/parameters/enable_process_reclaim
# END Motorola,IKSWM-36235
ProductName=`getprop ro.product.name`
if [ "$ProductName" == "msm8952_64" ] || [ "$ProductName" == "msm8952_64_LMT" ]; then
echo 10 > /sys/module/process_reclaim/parameters/pressure_min
echo 1024 > /sys/module/process_reclaim/parameters/per_swap_size
else
echo 50 > /sys/module/process_reclaim/parameters/pressure_min
echo 512 > /sys/module/process_reclaim/parameters/per_swap_size
fi
echo 70 > /sys/module/process_reclaim/parameters/pressure_max
echo 30 > /sys/module/process_reclaim/parameters/swap_opt_eff
I am not seeing a partition size here...
Swap partition is 512mb.
I've updated the first post to include flashable zips so it's easier to go back and forth if you don't like it.
Elemental kernel installed this does not kill zram.
MadGoat said:
Elemental kernel installed this does not kill zram.
Click to expand...
Click to collapse
Don't know what to tell you, this is for the stock rom/kernel.
MadGoat said:
Fully understand the performance impacts zram has now... And thank you for the explanation!
I however only have 2gb on this phone and zram has shown to be utilized to about 300 MB. However the zram partition is set at 512mb. It's like to play with 256 or 384 if I can. Ex manager allows zram partition sizes, however I would rather permanently change instead of an "after boot" tweak...
I see in the aforementioned file:
setprop ro.config.zram true
#Set per_process_reclaim tuning parameters
# BEGIN Motorola,IKSWM-36235
#echo 1 > /sys/module/process_reclaim/parameters/enable_process_reclaim
# END Motorola,IKSWM-36235
ProductName=`getprop ro.product.name`
if [ "$ProductName" == "msm8952_64" ] || [ "$ProductName" == "msm8952_64_LMT" ]; then
echo 10 > /sys/module/process_reclaim/parameters/pressure_min
echo 1024 > /sys/module/process_reclaim/parameters/per_swap_size
else
echo 50 > /sys/module/process_reclaim/parameters/pressure_min
echo 512 > /sys/module/process_reclaim/parameters/per_swap_size
fi
echo 70 > /sys/module/process_reclaim/parameters/pressure_max
echo 30 > /sys/module/process_reclaim/parameters/swap_opt_eff
I am not seeing a partition size here...
Click to expand...
Click to collapse
Instructions were clear - if you want to mess with it further, use an app or modify the ramdisk.
If you don't know how to modify the ramdisk, use an app.
Pretty sure this thread is about how to use the tool provided to turn it off as noted above, for the stock system.