Develop Bugs

"ReadyBoost" for Android?

Hello,
Why isnt it possible to use SDCRAM as sort of RAM in android? same as VISA/7 Using ReadyBoost to expand the ram with an USB disk on keys?
thanks!

Why would you want that?

since you only use flash based memory anyway: that's called swaping

And is Swap enabled in all froyo roms today?

rommark said:
And is Swap enabled in all froyo roms today?
Click to expand...
Click to collapse
But why would you need it? You have 512MB of RAM, with a clean boot you have around 200-220MB of it free for whatever you want to do with it. Not enough for you?

martino2k6 said:
But why would you need it? You have 512MB of RAM, with a clean boot you have around 200-220MB of it free for whatever you want to do with it. Not enough for you?
Click to expand...
Click to collapse
won't heavy 3d games eat that?

rommark said:
won't heavy 3d games eat that?
Click to expand...
Click to collapse
No. Smartphones =/= PCs. And if you are really out of space for a short amount of time, unneeded processes get killed automatically. Swap was only really needed on the G1 but definitely not on the Desire.

rommark said:
won't heavy 3d games eat that?
Click to expand...
Click to collapse
No, that's a bit too much even for a game... unless the code has memory leaks. With so much RAM it'd make more sense to use ramdisk (but who knows for what good use)

martino2k6 said:
No, that's a bit too much even for a game... unless the code has memory leaks. With so much RAM it'd make more sense to use ramdisk (but who knows for what good use)
Click to expand...
Click to collapse
RamDisk could be insane for 3d gaming as then the textures would have fast extraction means less delay in rendering....

What Readyboost is NOT
Hey folks. I've only recently discovered Readyboost as I'm primarily a Linux guy. I got all hot and bothered about it immediately as well as it is (despite Microsofts constant onslaught of horrific failures) an absolutely brilliant and elegant technology/idea.
HOWEVER!!!
Nearly everyone is confused about what RB actually does, so I thought I'd take a minute to explain.
ReadyBoost is NOT swap. NOT SWAP!, not swap.
Swap is not something to get excited about, it is a last resort for when you're out of RAM and it's excruciatingly slow. In the land of IT, one of the first things we check for when a server is experiencing horrible performance, is "IS THIS MACHINE SWAPPING". Everyone's gotta learn that swap, while it is more useful than "not enough memory" it is nor more useful than utilizing the memory you already have, and it will always result in poor performance.
ReadyBoost is an additional disc cache for small, non-sequential reads/writes. It works with your existing FS cache but is faster in some cases because FLASH has a much lower seek time. Most FLASH chips have a seek time of <1ms while most rotational discs have a seek time of around 8ms. This adds up on a large number of small non-sequential r/w.
ReadyBoost takes any caching operations which fit it's strength profile (small, non-sequential) and offloads them to your FLASH device. This can increase load speed of some files/application dramatically (2-20x faster).
So, when someone asks you if they can use Readyboost because they don't have enough memory, please, take a moment to explain that RB is not swap, but is in fact a supplementary disc cache for small, non-sequential reads and writes.
That said, I haven't had time to dig into the question of whether or not RB would benefit Linux FS's.

I know this is a really old thread but I just wanted to put my two cents in. Memory boosting apps like ReadyBoost do have a viable purpose. That is keeping older hardware viable as minimum specs increase. There is an Android app that is equivilant to ReadyBoost called Roehsoft RAM Expander. There are mixed reviews for its performance but that is to be expected. If this app helps my aging 8227_Demo head unit work well enough for me to not replace it I will update this post.

Has anyone tried the V6 Supercharger script?

http://forum.xda-developers.com/showthread.php?t=991276
Found that a couple days ago and was wondering if anyone has tried it or if most developers use something similar as a base.

I've tried it with Jermaine151's Minimalist ROM...and honestly I really don't notice any differences with how things run. My cousin, who has the OG Droid, swears by it.

localceleb said:
http://forum.xda-developers.com/showthread.php?t=991276
Found that a couple days ago and was wondering if anyone has tried it or if most developers use something similar as a base.
Click to expand...
Click to collapse
Kernel devs use a released kernel as a base, not a script. A kernel dev worth his salt has already made memory tweaks according to how he feels the system should run. I'm not sure what that script is supposed to fix or how lag and slow draw times are related to memory. Motorola devices are seriously challenged in that department, but HTC's are some of the best out there. I'm not sure where he came up with the idea that no-op IO queuing was as good as deadline. That's couldn't be more wrong. That also makes me question his other tweaks. Basically, if you're running a custom kernel, especially something like the seriously modified ziggy or AOSP kernels, I'd avoid this.

RMarkwald said:
I've tried it with Jermaine151's Minimalist ROM...and honestly I really don't notice any differences with how things run. My cousin, who has the OG Droid, swears by it.
Click to expand...
Click to collapse
Did you get the feeling it was really aimed at Motorola devices, too?

loonatik78 said:
Did you get the feeling it was really aimed at Motorola devices, too?
Click to expand...
Click to collapse
Yeah I did. I kinda figured that running a custom ROM/kernel combo would be ideal instead of running that script, just because the devs have tweaked/maximized their performance already.
I don't know if that's the case with a Moto device, as I have the Xoom but never owned the phone. My cousin swears by it on his OG Droid, and pointed it out to me.
Like you said, I think with HTC devices you won't really notice much, if any differences. I haven't personally.

RMarkwald said:
Yeah I did. I kinda figured that running a custom ROM/kernel combo would be ideal instead of running that script, just because the devs have tweaked/maximized their performance already.
I don't know if that's the case with a Moto device, as I have the Xoom but never owned the phone. My cousin swears by it on his OG Droid, and pointed it out to me.
Like you said, I think with HTC devices you won't really notice much, if any differences. I haven't personally.
Click to expand...
Click to collapse
Well, like I said, I'm suspect simply because he thinks no-op is a good IO scheduler. It kinda tells me he doesn't know his ass from a hole in the ground. No-op assumes mechanical storage mediums. Deadline is MUCH better for solid state storage, and all the rest of the schedulers are improvements that may or may not be better, depending on how you use your device.

I know deadline is better...but not all phones have deadline available.
I'm no guru on the topic and I go by what I read and read threads about the topic.
I don't take credit for the non-supercharger tweaks as they aren't mine and include links that I used as resources.
Yes I do say noop or deadline would be preferred over other common options on most devices. But the main thing is that both would be faster than what most people have configured - cfq.
btw, this thread seemed convincing that noop is performs very well on android
http://forum.xda-developers.com/showthread.php?t=948001
So forgive me for not consulting you first.
Oh, also...
NOOP scheduler is best used with solid state devices such as flash memory or in general with devices that do not depend on mechanical movement to access data (meaning typical "hard disk" drive technology consisting of seek time primarily, plus rotational latency). Such non-mechanical devices do not require re-ordering of multiple I/O requests, a technique that groups together I/O requests that are physically close together on the disk, thereby reducing average seek time and the variability of I/O service time.[2]
Click to expand...
Click to collapse
http://en.wikipedia.org/wiki/Noop_scheduler
But then again, you probably would have given me wrong information.
PS. So it seems that you're not all the bright either

zeppelinrox said:
I know deadline is better...but not all phones have deadline available.
I'm no guru on the topic and I go by what I read and read threads about the topic.
I don't take credit for the non-supercharger tweaks as they aren't mine and include links that I used as resources.
Yes I do say noop or deadline would be preferred over other common options on most devices. But the main thing is that both would be faster than what most people have configured - cfq.
btw, this thread seemed convincing that noop is performs very well on android
http://forum.xda-developers.com/showthread.php?t=948001
So forgive me for not consulting you first.
Oh, also...
http://en.wikipedia.org/wiki/Noop_scheduler
But then again, you probably would have given me wrong information.
PS. So it seems that you're not all the bright either
Click to expand...
Click to collapse
Yes. I'm aware of all that. The shortcoming of no-op is that it doesn't take into account demands of data. Some data should be fetched before other data, thus requiring a re-ordering of requests. It is best used on solid-state devices, but not THE best choice for them, necessarily. One might assume no-op to be roughly on par with deadline if some course assumptions about solid-state are made. No-op would be ideal on the SCSI5 array I built because a storage subsystem controller is re-ordering the data and caching it to memory. The latency times on that memory are exceeding low, as are write operations. In fact, the controller would send write-confirm commands back to the system even before data was actually written to disk to allow for more I/O operations. NAND solid-state is a different creature though. Read latency is certainly fast, however write latency is much, much slower in comparison. Because of this, simply throwing read and write commands at the storage subsystem wastes a lot of time since reads must wait on lengthy writes. Deadline holds significant advantage over no-op because it will suspend writes operations to ensure read request deadlines are met. In short, it mitigates some of the shortfall that comes with the NANDs lengthy write times. That's why I say it's significantly better.

I see.
That's very informative indeed.
Perhaps I can determine of a user has deadline available and if so, use that and if not, use noop

zeppelinrox said:
I see.
That's very informative indeed.
Perhaps I can determine of a user has deadline available and if so, use that and if not, use noop
Click to expand...
Click to collapse
I've never professed to be a software guy by any stretch of the imagination. I will never be able to do what you and many, many others do with software, code, Linux, scripting... and of that. I just don't understand that stuff. I'm very much the hardware geek though. Column address strobes? Sense amps? I get that kind of talk. Looking at a script? It might as well be in Sumerian.

zeppelinrox said:
I know deadline is better...but not all phones have deadline available.
I'm no guru on the topic and I go by what I read and read threads about the topic.
I don't take credit for the non-supercharger tweaks as they aren't mine and include links that I used as resources.
Yes I do say noop or deadline would be preferred over other common options on most devices. But the main thing is that both would be faster than what most people have configured - cfq.
btw, this thread seemed convincing that noop is performs very well on android
http://forum.xda-developers.com/showthread.php?t=948001
So forgive me for not consulting you first.
Oh, also...
http://en.wikipedia.org/wiki/Noop_scheduler
But then again, you probably would have given me wrong information.
PS. So it seems that you're not all the bright either
Click to expand...
Click to collapse
I forgot... I also wanted to explain that XDA thread a little.
It looks like he's basing his times on sequential writes, reads, then erases. Were that similar to real world use, his results would be valid, but seldom does anything work like that. Without knowing the specific IC of the flash drive in use, certain features of it can only be guessed at. Unless it's a virgin device or written to 0's, chances are writes are also going to come in conjunction with erases, which are a completely different process, and just as lengthy as writes. Because of how NAND works, larger erases and writes can be accomplished much faster by the address block rather than on a file by file basis. This is because NAND can only address blocks at a time. It has no random access capability for pages or bytes, either reading or writing. In short, his test demonstrates an ideal circumstance, one that is RARELY the circumstance of the real world.

I ran his V6 Supercharger script, Kick Ass Kernel Tweaks, and the 3G turbocharger tweaks in build.prop....
noticed NO difference whatsoever...
Actually, that isn't true. The one thing that seemed to work was the part about making the home launcher "hard to kill", that actually seemed to work. I was having issues with Sense restarting itself, and this alleviated that issue. I noticed that even if I tried to manually stop sense, I couldn't kill it. Two weeks later I removed all trace of the V6 scripts and haven't had any issues since, no idea why, although now I can manually kill the Sense process and have it restart again.
Anyways... no, there was no performance increase whatsoever.

bast525 said:
I ran his V6 Supercharger script, Kick Ass Kernel Tweaks, and the 3G turbocharger tweaks in build.prop....
noticed NO difference whatsoever...
Actually, that isn't true. The one thing that seemed to work was the part about making the home launcher "hard to kill", that actually seemed to work. I was having issues with Sense restarting itself, and this alleviated that issue. I noticed that even if I tried to manually stop sense, I couldn't kill it. Two weeks later I removed all trace of the V6 scripts and haven't had any issues since, no idea why, although now I can manually kill the Sense process and have it restart again.
Anyways... no, there was no performance increase whatsoever.
Click to expand...
Click to collapse
I was curious as to the Sense launcher restarting itself, and if this would fix/have an impact on that issue. Thanks for the info!

anyone that gave loonatik a hard time on this site seriously needs to reconsider, this guy knows his stuff.

loonatik78 said:
I forgot... I also wanted to explain that XDA thread a little.
It looks like he's basing his times on sequential writes, reads, then erases. Were that similar to real world use, his results would be valid, but seldom does anything work like that. Without knowing the specific IC of the flash drive in use, certain features of it can only be guessed at. Unless it's a virgin device or written to 0's, chances are writes are also going to come in conjunction with erases, which are a completely different process, and just as lengthy as writes. Because of how NAND works, larger erases and writes can be accomplished much faster by the address block rather than on a file by file basis. This is because NAND can only address blocks at a time. It has no random access capability for pages or bytes, either reading or writing. In short, his test demonstrates an ideal circumstance, one that is RARELY the circumstance of the real world.
Click to expand...
Click to collapse
I did think that the noop result was too good in relation to the other results.
I would not think that it was that much faster (since deadline is better) so I was somewhat surprised.
Thanks for elaborating

On the Sensation, the Supercharger script gave me no speed increase. It did fix my launcher redraws though. The only thing this script helped me with is multitasking, switching between apps constantly was smoother, and more often they didn't get killed by Android's task manager.
On the Nexus S though, it did make a good amount of difference in the operation of the phone.
I think, on the faster phones, like the SGS2 and the Sensation, it only helps with multitasking..

Well I initially came up with it because of the launcher redraw issue... everything else was gravy... well... a whole lotta gravy...
I don't think SuperSmoother sounds as cool so I'll stick with SuperCharger anyway lol

F2FS

Hey, I've been looking at switching from ext4 to F2FS, even if temporarly (I think I might like to have it permanently though). I don't dev, at least nothing of notice, but I was rather eager to test it out, after reading performance reports, testing it out on a SD card for myself, etc.. and as the original merge to the Linux kernel (found here) went in already, maybe we could benefit from this. It seems there's already an attempt to it (on the Nexus7 forum, here), and from what I've learned the major "issue" for the device itself would be to add the support for the filesystem in recovery (mkfs.f2fs) - needed for formatting /system, etc - but fuse/vold support would be necessary as well, no?
There's no fsck yet, but that is also true for btrfs and I use it at home with no major issues (while it has been in development way earlier than f2fs, I never had any data loss, for example, don't have many power outages at home so ), so that could wait a bit longer;
Would fastboot itself need to be modified for 'fastboot flash all' to work?
I'm posting this thread because I want to learn, not because I want to be spoonfed. Feel free to post your experiences with the filesystem, reading tips, kernel patches for 3.0.39 xD
links:
http://lwn.net/Articles/518988/

Definitely ambitious. Especially since Samsung only introduced it at the end of last year. A file system with nand storage in mind should also offer some kind of performance boost.

bk201doesntexist said:
links:
http://lwn.net/Articles/518988/
Click to expand...
Click to collapse
Really interesting article. Thanks for sharing. :thumbup:
Sent from my Galaxy Nexus

063_XOBX said:
Definitely ambitious. Especially since Samsung only introduced it at the end of last year. A file system with nand storage in mind should also offer some kind of performance boost.
Click to expand...
Click to collapse
Sure, it's probably not going to be easy, i.e.: just pull the project from kernel mainline/building (I remind everyone that it has been merged against linux3.8+), but I think we could see performance gains, there's a benchmark posted over @kernel mailing list against EXT4 and NILFS2; even with fsync on, it rules over the other two, both at sequential and random workload.
Quoting phoronix:
F2FS was tested from a desktop PC with an Intel Core i5 2500 CPU and then a Galaxy S3 running Android 4.0.4. F2FS beat EXT4 and NILFS2 in random and sequential buffered writes. F2FS also won with a write + fsync test. The mounting time was also measured. EXT4 was faster at mounting than F2FS, but the Samsung file-system did mount faster than NILFS2. In follow-up testing, F2FS also won with random reads.
Click to expand...
Click to collapse
Only thing it does take longer than EXT4 is at mounting devices, but we don't have external sd anyways so..
zAlbee said:
Really interesting article. Thanks for sharing. :thumbup:
Sent from my Galaxy Nexus
Click to expand...
Click to collapse
Yeah, it's a great topic, I feel we as a community could try to experiment with it. I for one can contribute with online time, testing, building, debugging.

Discussion on GCC Optimizations

As pretty much everyone here is aware, there seems to be an obsession with using O3 for compiling binaries for this device. This obsession is probably due to the fact that O3 is the "most optimized" flag in GCC. The issue here is that all of these optimizations do not come without drawbacks.
Technically, due to the nature of the Galaxy Nexus as a mid-spec ARM-based device, we should be using Os to reduce the size of the code that needs to be run.
Also, there are many other drawbacks to O3, such as significantly larger binary size and possible instability, which is why it is not default in the Linux kernel. Binary size does not only impact the size on disk, but can also impact processing time of the code and the amount of space that the program takes in the CPU cache and RAM.
If somebody could please show actual benchmark data showing that O3 optimization actually is an improvement compared to O2 and Os on the Galaxy Nexus, I would really appreciate seeing why it is used on nearly every ROM and kernel.
Edit: I also just read up on Ofast, which disables some standard compliance by simplifying math. I wonder if this would cause any stability issues on the Galaxy Nexus. I'd really like to try -Os -ffast-math when I have time.

I'm sorry, I don't have the time to do that, but I can say this. In all the time I've spent tinkering with compiler optimisations, -O3 has rarely been worth it. Especially on a system like the OMAP 4460 which suffers more from IO bottlenecking than MIPS or FLOPS being the bottleneck. It seems Google's default is -O2 and they have guys who know things about compilers. I would be very curious about -Os though, since that's basically -O2 with the code-bloating features turned off. But I suspect there won't be a perceptible difference.
My guess (again, don't have time to test this) is that since 3 is a bigger nummer than 2, it's used by people who don't know precisely what it does, which seems to be the MO for a lot of people who create ROMs.

borizz27 said:
My guess (again, don't have time to test this) is that since 3 is a bigger nummer than 2, it's used by people who don't know precisely what it does, which seems to be the MO for a lot of people who create ROMs.
Click to expand...
Click to collapse
I also believe that this is the case... I've even seen a ROM on another phone "compiled with O4", which just uses O3 (anything >3 just sets the optimization level to 3)...

During my brief stint in writing patches for Gentoo Linux back when my desktop computer was slower than my phone is now, I read all kinds of weird stuff. People with --ffast-math on complaining that math was wrong, for example, or people on tiny systems calling for complete loop unroll.
The GCC website is quite clear in what the different -O levels do: http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Optimize-Options.html#Optimize-Options
I would find it very odd someone at Google hasn't had the same idea and actually tested the different Olevels. I'm guesing O2 is where it's at.

borizz27 said:
During my brief stint in writing patches for Gentoo Linux back when my desktop computer was slower than my phone is now, I read all kinds of weird stuff. People with --ffast-math on complaining that math was wrong, for example, or people on tiny systems calling for complete loop unroll.
The GCC website is quite clear in what the different -O levels do: http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Optimize-Options.html#Optimize-Options
I would find it very odd someone at Google hasn't had the same idea and actually tested the different Olevels. I'm guesing O2 is where it's at.
Click to expand...
Click to collapse
Sure, and somebody who worked on Debian, Redhat, etc. also decided on O2 and it had just become a standard for stable, production-ready c builds.
Theoretically, due to the lack of sufficient cache on tiny ARM chips like the omap4, we should try to keep minimal code size through something like Os.
Also, I am assuming that ffast-math has improved because of the inclusion of Ofast in gcc4.6.

I hope to do some testing after I sync AOSP and fix errors with GCC 4.8

MДЯCЦSДИT said:
Sure, and somebody who worked on Debian, Redhat, etc. also decided on O2 and it had just become a standard for stable, production-ready c builds.
Theoretically, due to the lack of sufficient cache on tiny ARM chips like the omap4, we should try to keep minimal code size through something like Os.
Also, I am assuming that ffast-math has improved because of the inclusion of Ofast in gcc4.6.
Click to expand...
Click to collapse
I don't know. The 4460's cache is 1MB. While not huge, it's not tiny by any stretch of the imagination. However, I'm looking forward to your results. We can all keep guessing about what's best, but hard data will be better.
As far as I know, --ffast-math wasn't improved -- it still cuts the same corners and breaks the standard in the same places. -Ofast just combines -O3 with all the standards breaking options like --ffast-math.

Will doing a factory reset and disabling encryption speed up the phone at all?

I've heard that doing so alleviates some lag that people have been complaining about. Any truth to this?

First of all, please note that disabling decryption requires root, which also requires doing a factory reset. While disabling encryption will certainly speed up the phone, Google has improved encryption in Android Marshmallow so that it doesn't decrease performance as much as it did in Lollipop. You may not notice the difference. As for a factory reset, it will certainly get rid of any lag caused by any changes you made to the phone, but not any caused by Android.
Sent from my Nexus 5X using Tapatalk

Root and decryption are two different things. It seems you can have either or both. I'm curious to know if decryption carries a better experience myself also. I don't really care about benchmarks, mostly if it eliminates lag.

Every post I've read has said that they haven't noticed a difference between decrypted and encrypted with the 5X - though I haven't seen any benchmarks comparing. If it helps, the Ars Technica review shows how the I/O performance compares to previous phones. (3rd graph set in the Performance section)
I'm not sure whether it is actually a Marshmallow specific feature or not, but the 5X and the 6P are using the cryptography extensions that are part of the ARMv8 instruction set to perform encryption and decryption. The performance hit should be negligible.
Everyone clearly remembers the bad rep the N6 has for this, but it just didn't have proper support for this feature, though it apparently got a bit better later on. Right now it seems like jumping at ghosts for the 5X & 6P.
OP, which android build are you on? I'm wondering if the I build makes a difference. At least one person has returned their phone due to the lag, and had a replacement that didn't have that issue.

i was experiencing random lag with my n5x and I ended decrypting the phone and disabling zram and it made a big difference.
Before doing this, my phone was noticeably laggier and slower than my nexus 6 (decrypted). After decrypting and disabling zram, my n5x is now just as fast as my n6.
I did a speed test like those youtube videos, where you open apps at the same time and see which one finishes first, and now the n6 and n5x both finish opening apps almost exactly at the same time.

My build is mda89e. I don't have any noticeable lag, I was just curious if it would change anything.
How would you characterize the lag if it were present?

I decrypted and rooted, did not notice any difference in daily use. (dont care for benchmarks) I did however notice that the phone boots much faster after decryption.

dwang said:
i was experiencing random lag with my n5x and I ended decrypting the phone and disabling zram and it made a big difference.
Before doing this, my phone was noticeably laggier and slower than my nexus 6 (decrypted). After decrypting and disabling zram, my n5x is now just as fast as my n6.
I did a speed test like those youtube videos, where you open apps at the same time and see which one finishes first, and now the n6 and n5x both finish opening apps almost exactly at the same time.
Click to expand...
Click to collapse
How'd you disable zram?

lysm bre said:
How'd you disable zram?
Click to expand...
Click to collapse
I'd like to know this as well

Use trickster mod or kernel auditor to disable it.
Sent from my Nexus 5X using Tapatalk

Hi
Disabling ZRAM will wear out your flash memory quicker, the whole point of ZRAM is to speed up the phone and protect flash memory from hundreds or thousands of tiny write operations.
From the Wiki (https://en.wikipedia.org/wiki/Zram)
zram increases performance by avoiding paging to disk and using a compressed block device in RAM instead, inside which paging takes place until it is necessary to use the swap space on a hard disk drive. Since using RAM is an alternative way to provide swapping on RAM, zram allows Linux to make more use of RAM when swapping/paging is required, especially on older computers with less RAM installed.[1][2]
Even when the cost of RAM is low, zram still offers advantages for low-end hardware devices such as embedded devices and netbooks. Such devices usually use flash-based storage that has limited lifespan due to its nature, which is also used to provide swap space. The reduction in swap usage as a result of using zram effectively reduces the amount of wear placed on such flash-based storage, resulting in prolonging its usable life. Also, using zram results in a significantly reduced I/O for Linux systems that require swapping.[3][4]
Click to expand...
Click to collapse
Decryption doesn't make much difference (it will speed up boot times if you had a power on password, but that is simply because it is booting twice to offer us a protected Android environment first to get the password, and this was optional anyway, we get the choice during setup). The whole phone isn't encrypted anyway, just user data, hence overall the difference between encrypted and decrypted isn't that wide.
Unless we have some evidence of the speed up, I'm tempted to put down any suggestion of speed up down to the placebo effect :laugh:
If there is an improvement, It might be as simple as a factory reset is good for the phone due to some optimization undertaken with the flash memory at that time, or recompiling apps, that has been skipped when loading the device with an image at the factory. Perhaps that is why some people are seeing no problems with lag because they've played about first and had a mess around, then did a factory reset at some point to set up their device up as a daily driver.
A true test would be to do factory reset with everything at defaults, run a measured test, then decrypt and remove ZRAM and do a second test.
Regards
Phil

This is wrong. Disabling zram doesn't mean u are adding a swap to the flash, so the kernel isn't going to write to the flash.
You have no idea what you are talking about.
Sent from my Nexus 5X using Tapatalk