would it be possible to change the filesystem from ext4 to btrfs with compression and ssd optimization.
i do have the knowledge about the possible of having more cpu overhead than the improvement in transfer speed.. but when it comes to space saving, i think it does worth it. i have been using btrfs compression on opensuse for quite a while. the space saving is amazing. with compression enabled, the space usage is half the normal size.
the only concern im having about getting this to be done is the kernel. does the kernel we are using support btrfs compression at the first place(mblaster?)? i do not have the technical knowledge of how to get this done. hope someone could turn this idea to a reality.
gingerboy92 said:
...does the kernel we are using support btrfs compression at the first place(mblaster?)?
Click to expand...
Click to collapse
Nope, sorry. Btrfs is not in atm (could be changed for a test), but I don't know if compression would be supported. Also I am not convinced that compression would help a lot on the folio for two reasons: First the compression end uncompression both need cpu cycles, slowing down the system. And second the kind of files you typically have on such a device (mp3, videos etc.) are not really compressable. I doubt you would get more then a few percent more storage out of your device.
ehem.. about the cpu cycle, lzo compression could reduce the cpu usage, but i don't know by how much, probably still wouldn't worth the gain too. i don't know. but even if it does gives a worthy gain, maybe there's too much work to be done, lzo needs kernel 2.6.38 kernel to work if i'm not mistaken. compression(if possible) could be applied to something like the boot partition? maybe it could improve boot time, just a maybe.
looks like i didn't consider everything before i speak. thanks mblaster. ^.^
mblaster said:
Nope, sorry. Btrfs is not in atm (could be changed for a test), but I don't know if compression would be supported. Also I am not convinced that compression would help a lot on the folio for two reasons: First the compression end uncompression both need cpu cycles, slowing down the system. And second the kind of files you typically have on such a device (mp3, videos etc.) are not really compressable. I doubt you would get more then a few percent more storage out of your device.
Click to expand...
Click to collapse
True, what is stored on storage ? Mp3, mp4? ~ all of them are mostly compressed, where other - mathematical/lossles compression wouldnt help - in most cases would it make worse
gingerboy92 said:
ehem.. about the cpu cycle, lzo compression could reduce the cpu usage, but i don't know by how much, probably still wouldn't worth the gain too. i don't know. but even if it does gives a worthy gain, maybe there's too much work to be done, lzo needs kernel 2.6.38 kernel to work if i'm not mistaken. compression(if possible) could be applied to something like the boot partition? maybe it could improve boot time, just a maybe.
looks like i didn't consider everything before i speak. thanks mblaster. ^.^
Click to expand...
Click to collapse
compression is already applied on kernels.
usually you compile a kernel into bzImage, the "z" just means it's compressed.
modern linux kernels allow you to choose from gzip, bzip2, lzma, xz, lzo, lz4.
this includes ramdisk.
If you need space, just use an sdcard or microusb or Mount a network share...
Gesendet von meinem folio100 mit Tapatalk
Related
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.
Hi,
I've built some kernels that can be applied to the MiRaGe CM7 build. Below are the changes of each kernel build.
The 16 BPP frame buffer uses 16 bits per pixel instead of 32 bits per pixel. This reduces the amount of memory used for the screen frame buffer. It also means that when Android updates the screen, it has to move half the amount of data. This has the potential to increase performance. The potential downside is color banding. Using fewer bits for each pixel reduces the number of colors that can be displayed. I haven't noticed a difference in how the screen looks.
Compiling the kernel for speed versus size tells the compiler to use more memory if it will make the code run faster. This tradeoff uses less than 256k more memory (the Nook has 524288k) for the kernel.
By default, the backlight is turned on and off at a base frequency of 128 times per second. If you are at 50% brightness it will be turned on and off 128 times in one second. The 256Hz kernel doubles the rate at which the backlight is turned on and off as some people can see the backlight flashing at 128Hz. Since the switching is done in an interrupt to the processor, there is more overhead at the higher frequency so it's not a free change. Only use if the default screen seems to flicker.
encore_kernel_07302012.zip:
- 16 BPP frame buffer
- Compiled with -O2 instead of -Os (speed instead of size)
encore_kernel_256Hz_07302012.zip:
- same as above and 256Hz backlight instead of 128Hz
encore_kernel_07122012.zip:
- 16 BPP frame buffer
- Compiled with -O2 instead of -Os (speed instead of size)
encore_kernel_256Hz_07122012.zip:
- same as above and 256Hz backlight instead of 128Hz
Attached are CWM zips you can apply to probably any recent MiRaGe build.
Frank
For the uninitiated, what does this do? (layman's terms)
And how do you apply it?
Sent from my NookColor using xda premium
The kernel is the engine that drives your rom. It is the core of the system, responsible for drivers, modules and managing the communication between hardware and software, among other responsibilities. You already have one, you just don't have this one made just for you.
Looks like frankusb has put it into a flashable zip, so just flash it over your Mirage rom.
Alternatively, for emmc installs, you could just take out the uImage file from the zip, rename it to kernel and put it in any rom you want.
If you have an sd install, just replace the uImage in your boot partition with his.
------------------------------------------------------------------------------------------
off-topic​
I've been following the 3.x kernel thread over at the Nook Tablet forum, as well as building and configuring my own from keyodi's source.
I'm not very good at it yet, though, and that's kind. My kernel builds tend to boot and I was able to enable the NAT stuff on my own (before the new .config was pushed) but that's as far as I have gone with it.
I wouldn't mind having a thread where kernel development was discussed, although frankusb, maybe you would rather keep the discussion on your kernel.
Here is fattire's post at the acclaim forum, urging people to try and build their own kernel. (with links and guides)
slack04 said:
For the uninitiated, what does this do? (layman's terms)
Click to expand...
Click to collapse
- The LEDs that bring light to the screen flash twice faster, so it should be less noticeable, especially at lower brightness levels and a darker room. You might have noticed that cameras (see Youtube) also see the Nook Color flickering.
- The screen is now updated at 60Hz instead of 44 frames per second. Most laptop/desktop LCDs are run at 60Hz. Can make it possible to have smoother graphics. Does give the programs a harder time to keep up if they try to do this, since they need to push 40% more image data per second.
- With half the bits (32 vs 16) to push to the display, graphics get slightly faster. I believe this is optional in Cyanogenmod settings.
---------- Post added at 07:47 AM ---------- Previous post was at 07:31 AM ----------
Over from the Mirage main topic:
Henk Poley said:
I'm talking about the backlight. On a static image I can distinctly see the corners of the display in a stroboscopic effect when I move the Nook Color by hand. As if the image quickly disappears and then time travels to another spot . It's quite annoying and possibly tiring.
(Probably spaced ~78mm)
Click to expand...
Click to collapse
With this kernel build I now see the flickering at a reduced distance when I move the nook color by hand. It does look like half the distance, like it should
Still noticeable though.
There is a bug now, that ever so often 100% brightness in RootDim puts the backlight brightness all the way down. I wonder if the unmodified driver has a similar race condition in writing the value to the PWM divider register.
mateorod said:
The kernel is the engine that drives your rom. It is the core of the system, responsible for drivers, modules and managing the communication between hardware and software, among other responsibilities. You already have one, you just don't have this one made just for you.
Looks like frankusb has put it into a flashable zip, so just flash it over your Mirage rom.
Alternatively, for emmc installs, you could just take out the uImage file from the zip, rename it to kernel and put it in any rom you want.
If you have an sd install, just replace the uImage in your boot partition with his.
------------------------------------------------------------------------------------------
off-topic​
I've been following the 3.x kernel thread over at the Nook Tablet forum, as well as building and configuring my own from keyodi's source.
I'm not very good at it yet, though, and that's kind. My kernel builds tend to boot and I was able to enable the NAT stuff on my own (before the new .config was pushed) but that's as far as I have gone with it.
I wouldn't mind having a thread where kernel development was discussed, although frankusb, maybe you would rather keep the discussion on your kernel.
Here is fattire's post at the acclaim forum, urging people to try and build their own kernel. (with links and guides)
Click to expand...
Click to collapse
Are you building for Nook Color or Tablet?
Sent from my NookColor using xda premium
This kernel works for Nook Color.
Henk Poley said:
There is a bug now, that ever so often 100% brightness in RootDim puts the backlight brightness all the way down. I wonder if the unmodified driver has a similar race condition in writing the value to the PWM divider register.
Click to expand...
Click to collapse
You are very observant. This driver has an interesting detail.
There are cases where there is a 1/8 second delay before the brightness level is set.
I've noticed even before my change of frequency that sometimes when it dimmed the screen due to inactivity, it would flash full brightness.
Side note: This driver was originally written by Nokia, probably for either the 770 or N800. The 770 was my first internet tablet.
Frank
mateorod said:
I wouldn't mind having a thread where kernel development was discussed, although frankusb, maybe you would rather keep the discussion on your kernel.
Click to expand...
Click to collapse
I'm certainly OK with this thread discussing kernel development. I've been enjoying building the Nook kernel lately.
I doubt there's much to discuss about my particular kernel, at least so far, the changes are very minimal and mostly well known. The LED PWM frequency is the only new change.
Frank
Ur kernel makes the reading easier on eyes. Especially white background isn't too bright on webpages.
I think CPU adds 5% performance gains too.
However, can I apply this kernel on top of future upcoming mirage releases?
manic77 said:
However, can I apply this kernel on top of future upcoming mirage releases?
Click to expand...
Click to collapse
It depends on what mrg666 ends up doing but since I enjoy his rom, I'll probably keep this kernel current.
Frank
So...have you done any experimenting with different toolchains? I was originally using the one that I built making cm9, but then switched to the prebuilt linaro tool chain. I just recently installed the new 12.04 with 4.7 in it. I have seen the claim, (mrg666 makes it, for instance) that using certain toolchains gives performance advantages. I can't tell personally, but it's not like I put 'em through benchmarking or stress tests.
Anyway, the point is that I am debating building and configuring the 12.04 toolchain myself. What do you know, do you think it's worth it? I may just do it for the learning experience, regardless.
mateorod said:
So...have you done any experimenting with different toolchains? I was originally using the one that I built making cm9, but then switched to the prebuilt linaro tool chain. I just recently installed the new 12.04 with 4.7 in it. I have seen the claim, (mrg666 makes it, for instance) that using certain toolchains gives performance advantages. I can't tell personally, but it's not like I put 'em through benchmarking or stress tests.
Anyway, the point is that I am debating building and configuring the 12.04 toolchain myself. What do you know, do you think it's worth it? I may just do it for the learning experience, regardless.
Click to expand...
Click to collapse
I started with gcc 4.4 and then moved to Linaro 4.5. The kernel size got smaller but that's about all I can say. I have not come up with a good way to benchmark just the kernel (since that's all I'm recompiling). Android benchmarks don't seem repeatable to me. Way too much variance between runs. Also Android benchmarks aren't really testing just the kernel.
Then a source code change was required to move to Linaro 4.6. That's what I'm currently compiling with.
I did make one build with Linaro 4.7 from the 12.04 release but the kernel did not boot for me.
Frank
I didn't think the screen could get any better. I would use this but every time the screen times out it doesn't want to turn back on or when it does it gets really dim and touch is non responsive.
Sent from my NookColor using Tapatalk 2
I'm having trouble downloading the 7-1 kernel from my desktop (404 not found). Mirror or link fix, please?
foxalot said:
I'm having trouble downloading the 7-1 kernel from my desktop (404 not found). Mirror or link fix, please?
Click to expand...
Click to collapse
Weird - uploaded to a file host as well.
Frank
Great update and great work on the kernal once again. keep it up . can't wait to see everyone's work on 3.xx
Just installed Mirage 070512 and now confused as to which kernel to go with. Do I stick with the kernel from Mirage or do I flash one of the kernels in the OP? If OP, what are differences of the 3 kernels? I like the idea of 256, but not sure if 7/1 kernel also has 256? Appreciate any advice on this.
Sent from my NookColor using xda premium
360Razir said:
Just installed Mirage 070512 and now confused as to which kernel to go with. Do I stick with the kernel from Mirage or do I flash one of the kernels in the OP?
Click to expand...
Click to collapse
Your choice, the stock mrg666 kernel will work. Probably any of the 3 I built will work as well with the 070512 Mirage build.
360Razir said:
If OP, what are differences of the 3 kernels? I like the idea of 256, but not sure if 7/1 kernel also has 256? Appreciate any advice on this.
Click to expand...
Click to collapse
The 3 kernels are snapshots in time of 3 mrg666 stock kernels with my changes listed. The 7/1 kernel does not have a 256Hz refresh rate. I'd be glad to make one for you if you or others are interested. The increased refresh rate didn't do anything for me, but a 16 bit frame buffer and a different optimization did.
Frank
frankusb said:
Your choice, the stock mrg666 kernel will work. Probably any of the 3 I built will work as well with the 070512 Mirage build.
The 3 kernels are snapshots in time of 3 mrg666 stock kernels with my changes listed. The 7/1 kernel does not have a 256Hz refresh rate. I'd be glad to make one for you if you or others are interested. The increased refresh rate didn't do anything for me, but a 16 bit frame buffer and a different optimization did.
Frank
Click to expand...
Click to collapse
Thanks for the feedback, Frank. I will start with your 7/1 kernel and go from there. If you can make 256 with 7/1 then great...I will gladly put it through its paces. Thanks for all your efforts thus far.
Sent from my NookColor using xda premium
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
Has anyone every tried this on the z5c? what are your experiences?
the biggest bottleneck on the device is the ram (and the android system already uses a lot)
I have same question.
on my old sony i manage to do swap partition without any special kernel , just rooted and use auto app\terminal\script
ill do the same when my warranty will over
there is a zram built in to the aosp... is that the same?
AlphaDream0 said:
swap partition
Click to expand...
Click to collapse
SWAP is slow and not stable. ZRAM in this plan the better.
NeoBeum said:
there is a zram built in to the aosp... is that the same?
Click to expand...
Click to collapse
Standard ZRAM is not bad, but it has to be optimized with patches to enable LZ4 compressor and then it will be fine.
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.