Related
Hi all, specifically Dexter. I am posting in General as I cannot post in Dev just yet.
I am a linux sysadmin by trade and I have a couple of filesystem performance mods that I use on SSD that I have ported to my A7. I was wondering about the chances of adding them into a future Dexmod, should there be one.
- Set default scheduler to deadline
I have seen posts about using 'noop' which works fine, but using 'deadline' optimizes the reads over writes which bumps performance slightly. Note using deadline slows down sync's a bit on unmount (more data to sync).
This needs a change to the kernel boot options if you are able to mod the boot loader, the option is:
elevator=deadline
Or it could be done after boot with
echo deadline > /sys/block/mmcblk0/queue/scheduler
echo deadline > /sys/block/mmcblk3/queue/scheduler
- Add trim support to the filesystems
This will enhance garbage collection and extend SSD life. Simply add the 'discard' option to the mounts.
- Possibly change the mount option to noatime?
I am not actually sure if this will work on an android device, it all depends on how heavily the system makes use of file access times. I would say none, but since android actively puts a lot of tasks to sleep it may need atime for some reason. I have not tried it yet, just in case. If it will work this will speed things up and extend SSD life by reducing disk writes.
So if this will not bork the system, change the mount option from 'relatime' to 'noatime'.
Cheers!
Domito
domito said:
- Set default scheduler to deadline
I have seen posts about using 'noop' which works fine, but using 'deadline' optimizes the reads over writes which bumps performance slightly. Note using deadline slows down sync's a bit on unmount (more data to sync).
This needs a change to the kernel boot options if you are able to mod the boot loader, the option is:
elevator=deadline
Or it could be done after boot with
echo deadline > /sys/block/mmcblk0/queue/scheduler
echo deadline > /sys/block/mmcblk3/queue/scheduler
Click to expand...
Click to collapse
this can be done.. the "echo" solution is probably the easiest one, as boot.img somehow is different to add kernel args to.
but if it helps we will see..
domito said:
- Add trim support to the filesystems
This will enhance garbage collection and extend SSD life. Simply add the 'discard' option to the mounts.
- Possibly change the mount option to noatime?
Click to expand...
Click to collapse
ill check up on these options.
Dexter_nlb said:
this can be done.. the "echo" solution is probably the easiest one, as boot.img somehow is different to add kernel args to.
but if it helps we will see..
Click to expand...
Click to collapse
You are probably right, I had the same issue when I was trying to mod my Gentouch. It would be much easier if the kernel source was available (wishful thinking).
Dexter_nlb said:
ill check up on these options.
Click to expand...
Click to collapse
Thanks!
Domito
P.S. Love the mod, thanks for all the hard work.
domito said:
This will enhance garbage collection and extend SSD life.
Click to expand...
Click to collapse
TY for bringing your expertise to the Elocity world
I was just curious, are the SSD's used in the EA7 really subject to such quick degradation? How can you tell if your SSD is having issues? I dont have that much experience with them yet, I did notice my Desktop SSD had a MTBF of 2,000,000 hours (228 years)...but I know MTBF isnt the same thing as losing blocks.
TheZedo said:
TY for bringing your expertise to the Elocity world
Click to expand...
Click to collapse
I like to help when I can.
TheZedo said:
I was just curious, are the SSD's used in the EA7 really subject to such quick degradation? How can you tell if your SSD is having issues? I dont have that much experience with them yet, I did notice my Desktop SSD had a MTBF of 2,000,000 hours (228 years)...but I know MTBF isnt the same thing as losing blocks.
Click to expand...
Click to collapse
The key issue is not 'how long does the drive last' but 'why not make it last longer'. All SSD are subject to degredation over time due wear caused by write amplification (check wikipedia, the forum will not let me post external links).
I think I saw someone post the actual make/model of the SSD in another thread, it might be fun to look up the specs at the manf. site (if available).
Normally on a linux system I would watch for signs of issues in the logs, dmesg in particular. I think it would be much like ECC memory, it'll just happily go along without the bad blocks in use. There could be a better way, I'll look into it. Smartctl may show something. The only clue you'll get on android is the dmesg output.
I just had to restore my desktop because a 2 month old OCZ SSD failed on me. It did not outright fail though, that would be too easy. It worked for a while, then failed, then worked after reboot, then failed. Very annoying. I am not sure if this was caused by write amplification, or just a crappy SSD. YMMV.
Hey guys, just wondering why has changing perms for system apps been disabled on purpose in Omni's App Ops? See here.
Was that to accomodate for non-rooted setups? Thanks for info.
golden-guy said:
Hey guys, just wondering why has changing perms for system apps been disabled on purpose in Omni's App Ops? See here.
Was that to accomodate for non-rooted setups? Thanks for info.
Click to expand...
Click to collapse
I believe so... The change is a squash of changes from CodeAurora (Qualcomm).
But diddling with permissions of system apps is a great way to interfere with system stability (if it even works at all because system apps fundamentally have increased permissions).
If you don't trust someone's system apps, you shouldn't be running their stuff at all.
Entropy512 said:
I believe so... The change is a squash of changes from CodeAurora (Qualcomm).
But diddling with permissions of system apps is a great way to interfere with system stability (if it even works at all because system apps fundamentally have increased permissions).
If you don't trust someone's system apps, you shouldn't be running their stuff at all.
Click to expand...
Click to collapse
That's oh so true. Still it might come in handy for wakelocks, apart from the privacy aspect.
Thanks! :good:
golden-guy said:
That's oh so true. Still it might come in handy for wakelocks, apart from the privacy aspect.
Thanks! :good:
Click to expand...
Click to collapse
I've never been a fan of outright blocking wakelocks, as it can cause some REALLY weird stuff.
The main issue here might be gapps - since those are system apps BUT closed-source. Any of the open-source stuff, people can actually look at the source and see whether or not there actually is a privacy issue. (This reminds me of when some dude came here ranting about horrible privacy issues in OmniTorch because it had system app permissions, even though he couldn't find a single example of it collecting data because it WASN'T collecting data...)
I believe that outright blocking wakelocks in gapps is likely to cause some strange problems - the blocking/stretching of alarms makes more sense (I don't like those damned NLPCollectorWakeLocks either, which is why I've been playing with some stuff that stretches out the alarm timers for it - check gerrit for some WIP stuff on that.)
Thanks for all the info, I have now decided to introduce a new build.prop in my builds that allows for controlling system apps if set to true. It's the least intrusive approach imho:
https://github.com/golden-guy/android_patchsets_samsung_golden/blob/android-5.1/packages/apps/Settings/0001-Settings-Introduce-prop-to-allow-AppOps-on-system_ap.patch
Today Google posted factory images for December. All supported phones except the Nexus 6 got a 7.1 build, hopefully ours comes soon!
Great ... here we go again. Anyone know the difference between the S and U variants???
steve841 said:
Great ... here we go again. Anyone know the difference between the S and U variants???
Click to expand...
Click to collapse
NBD91S contains the old bootloader with the old Google logo for some unknown reason.
The build date\time between the two builds is only approx 11 hours with NBD91U being the newest.
Not entirely sure why NBD91S exists. Will probably know shortly once AOSP code base is updated.
xdatastic said:
NBD91S contains the old bootloader with the old Google logo for some unknown reason.
The build date\time between the two builds is only approx 11 hours with NBD91U being the newest.
Not entirely sure why NBD91S exists. Will probably know shortly once AOSP code base is updated.
Click to expand...
Click to collapse
Thanks! I was wondering myself. I'm tempted to flash the new build, but I think I'll hold out until the 7.1 image is posted!
H4X0R46 said:
Thanks! I was wondering myself. I'm tempted to flash the new build, but I think I'll hold out until the 7.1 image is posted!
Click to expand...
Click to collapse
I was thinking the same, but we could be waiting a month or so if the rollout is anything like with Android 7.0.
As long as when 7.1.1 is released the build is newer than "ro.build.date=Thu Oct 27 23:10:15 UTC 2016", the OTA should upgrade just fine over the top of NBD91U.
xdatastic said:
I was thinking the same, but we could be waiting a month or so if the rollout is anything like with Android 7.0.
As long as when 7.1.1 is released the build is newer than "ro.build.date=Thu Oct 27 23:10:15 UTC 2016", the OTA should upgrade just fine over the top of NBD91U.
Click to expand...
Click to collapse
I always keep mine unencrypted so updates are a no no lol the down side of it, I have to manually flash all my builds so I don't get encrypted. But I hope the rollout doesn't take a month! The 7.0 situation was terrible! I mean, it's still a Nexus! Haha
H4X0R46 said:
I always keep mine unencrypted
Click to expand...
Click to collapse
a little off-topic, but out of interest, why do you do that? Does it perform better?
xdatastic said:
a little off-topic, but out of interest, why do you do that? Does it perform better?
Click to expand...
Click to collapse
Off topic is cool lol I do it mostly because I use multirom, and really just to keep things simple. I always flash non force encrypted kernels into my secondary roms as well, but mostly for multirom and to avoid it's complications! As far as better performance, I'm not sure, I've always ran mine unencrypted.
steve841 said:
Great ... here we go again. Anyone know the difference between the S and U variants???
Click to expand...
Click to collapse
Wouldn't a better question be if anyone knows the difference between this thread and the other one that was started a couple hours earlier on the same topic?
xdatastic said:
a little off-topic, but out of interest, why do you do that? Does it perform better?
Click to expand...
Click to collapse
Yes, the phone feels a lot smoother when unencrypted. (Scrolling, animations, etc)
wazza1991 said:
Yes, the phone feels a lot smoother when unencrypted. (Scrolling, animations, etc)
Click to expand...
Click to collapse
Not to mention it boots in just a few seconds vs what feels like an hour when encrypted
---------- Post added at 02:25 PM ---------- Previous post was at 01:57 PM ----------
H4X0R46 said:
Today Google posted factory images for December. All supported phones except the Nexus 6 got a 7.1 build, hopefully ours comes soon!
Click to expand...
Click to collapse
There is already a thread for this exact same thing.
I know a lot of people get bent out of shape when people don't search before posting, and I'm not generally one of those people, but honestly this is a little ridiculous. You didn't even have to search... all you had to do was open your eyes and look. It's been one of the top two threads in the "General" section (the section where you posted this) since yesterday.
wazza1991 said:
Yes, the phone feels a lot smoother when unencrypted. (Scrolling, animations, etc)
Click to expand...
Click to collapse
xdatastic said:
a little off-topic, but out of interest, why do you do that? Does it perform better?
Click to expand...
Click to collapse
In my experience it was really only beneficial on Lollipop. On Marshmallow it wasn't as noticeable. On Nougat the difference isn't noticeable at all. It's fast and smooth, encrypted or not.
I do agree with longer boot times when encrypted, but it's only an extra 20 seconds or so. No big deal
Ignore
H4X0R46 said:
Ignore
Click to expand...
Click to collapse
Lol. Done
demarcmj said:
Lol. Done
Click to expand...
Click to collapse
Well, glad to see there's ANOTHER elitist minded member here.
Face_Plant said:
In my experience it was really only beneficial on Lollipop. On Marshmallow it wasn't as noticeable. On Nougat the difference isn't noticeable at all. It's fast and smooth, encrypted or not.
I do agree with longer boot times when encrypted, but it's only an extra 20 seconds or so. No big deal
Click to expand...
Click to collapse
A lot of people claim better battery life as well! I always stay unencrypted so I don't really know the difference. Is there really any measurable difference?
H4X0R46 said:
A lot of people claim better battery life as well! I always stay unencrypted so I don't really know the difference. Is there really any measurable difference?
Click to expand...
Click to collapse
I'll find out soon. I've been unencrypted since I bought my Nexus 6 last summer and got between 5-7 hours of SOT (depending on how I setup/used my phone). I recently updated to Nougat and accidentally encrypted my phone. I don't feel like formatting data and copying over my 50+ gigs of movies, music, etc again, so we'll see how much of an impact it has on battery life (if any).
H4X0R46 said:
Well, glad to see there's ANOTHER elitist minded member here.
Click to expand...
Click to collapse
Like I said, I don't normally condone the constant jumping down people's throats when they, for example, ask a question that was already covered 342 pages earlier in the thread. Honestly I feel like any time I ask a question in a ROM thread I need to start with some form of "Sorry if this was already covered. I tried searching but..."
It's just that this was a pretty egregious instance.
demarcmj said:
Like I said, I don't normally condone the constant jumping down people's throats when they, for example, ask a question that was already covered 342 pages earlier in the thread. Honestly I feel like any time I ask a question in a ROM thread I need to start with some form of "Sorry if this was already covered. I tried searching but..."
It's just that this was a pretty egregious instance.
Click to expand...
Click to collapse
Well alright man, fair enough. When I posted mine I actually didn't see a thread about it, saw one after refreshing the page like an hour later lol
The NBD91S factory image, ota, and binaries have been removed. Was likely released in error as it contained an old bootloader version.
NBD91U/7.0.0_r24 source has just pushed to AOSP. Syncing repo now so can take a look at the commits.
---------- Post added at 11:47 AM ---------- Previous post was at 10:57 AM ----------
Here are the AOSP commits for NBD91P/7.0.0_r19 to NBD91U/7.0.0_r24:
project bionic/
e6c2570 Fix a linking error in bionic/tests
3933127 Fix a linking error in bionic/tests
719e285 Fix a linking error in bionic/tests
project build/
e820b05 Updating Security String to 2016-12-05
9889192 Updating Security String to 2016-12-01
d4fe133 NBD91U
462bdc2 NBF27
644a954 NBD91T
b5375b4 Updating Security String to 2016-12-05
a17475e Updating Security String to 2016-12-01
3de4cf3 NBF27
e26b6c6 NBF26
47a4723 NBD91S
cedc4e2 Updating Security String to 2016-12-05
1b12907 Updating Security String to 2016-12-01
84e53c2 NBD91R
1c67845 Update security string to 2016-11-06 for nyc
b51bb2e NBF26
ce0040f NBD91Q
7a5a9de Update security string to 2016-11-06 for nyc
project device/htc/flounder/
d4bedc7 Xtra Patch - https
850918b Xtra Patch - https
107502e Xtra Patch - https
project device/huawei/angler/
4854b2f Xtra Fixes - https, version check & version 3
04afcab Xtra Fixes - https, version check & version 3
89a73f0 Xtra Fixes - https, version check & version 3
project device/lge/bullhead/
ae0d62c Xtra Fixes - https, version check & version 3
2f201ad Xtra Fixes - https, version check & version 3
fc5fca8 Xtra Fixes - https, version check & version 3
project device/lge/bullhead-kernel/
d23f0a1 bullhead: update prebuilt kernel [ DO NOT MERGE ]
project device/moto/shamu/
9dad036 Xtra Patch - https
30e2b48 Xtra Patch - https
072f03a Xtra Patch - https
project external/boringssl/
75d9066 DO NOT MERGE: Add a few more no-op stubs for cURL compatibility.
b1da1d7 DO NOT MERGE: Add a few more no-op stubs for cURL compatibility.
611692f DO NOT MERGE: Add a few more no-op stubs for cURL compatibility.
project external/curl/
14929b8 Update and re-run androidconfigure.
a4b11cd Update libcurl from 7.49.1 to 7.50.1.
a67de91 Update and re-run androidconfigure.
a38aa1c Add README.version and update script.
21b0de3 Update libcurl from 7.43 to 7.49.1
6ba31fb Remove bogus dependency on <sys/utime.h>.
b05010e Update and re-run androidconfigure.
de0a91c Update libcurl from 7.49.1 to 7.50.1.
9cdb818 Update and re-run androidconfigure.
6239d30 Add README.version and update script.
fddeae5 Update libcurl from 7.43 to 7.49.1
f712982 Remove bogus dependency on <sys/utime.h>.
06842e3 Update and re-run androidconfigure.
bd91a89 Update libcurl from 7.49.1 to 7.50.1.
c0c2e5f Add README.version and update script.
18e9694 Update and re-run androidconfigure.
7167103 Update libcurl from 7.43 to 7.49.1
a1ded0a Remove bogus dependency on <sys/utime.h>.
project external/libavc/
c0d86a2 Decoder: Fixes in handling errors in Mbaff clips.
eee053f Decoder: Ignore few dpb errors
5124530 Decoder: Fixes in handling errors in Mbaff clips.
d6fe693 Decoder: Ignore few dpb errors
31deb23 Decoder: Fixes in handling errors in Mbaff clips.
43b0849 Decoder: Ignore few dpb errors
project frameworks/av/
8705ead Fix potential NULL dereference in Visualizer effect
19cb0bd Fix divide by zero
9d30f9a MPEG4Extractor: Check mLastTrack before parsing btrt box.
7d0a568 Fix potential NULL dereference in Visualizer effect
9281881 Fix divide by zero
2552ca9 MPEG4Extractor: Check mLastTrack before parsing btrt box.
323a9c7 Fix divide by zero
bd501c3 Fix potential NULL dereference in Visualizer effect
1aa3f25 MPEG4Extractor: Check mLastTrack before parsing btrt box.
project frameworks/base/
a7179cd ExifInterface: Provide backward compatibility
4744ea7 DO NOT MERGE Isolated processes don't get precached system service binders
af53690 Fix launching alarm pending intent
aaa09aa Force APKs to be streamed
83b7d9a DO NOT MERGE Isolated processes don't get precached system service binders
df7714e Fix launching alarm pending intent
4da7604 Force APKs to be streamed
cf4e893 DO NOT MERGE Isolated processes don't get precached system service binders
f460753 Fix launching alarm pending intent
4396456 Force APKs to be streamed
965e4f2 ExifInterface: Provide backward compatibility
project frameworks/ex/
4d40549 Handle color bounds correctly in GIF decode.
8cfb35c Handle color bounds correctly in GIF decode.
b7ab8d0 Handle color bounds correctly in GIF decode.
project frameworks/opt/net/wifi/
96d8d99 resolve merge conflicts of 849c5c7 to mnc-dev
fa8f7e4 wifinative jni: check array length to prevent stack overflow
c108260 resolve merge conflicts of 849c5c7 to mnc-dev
8d3656e wifinative jni: check array length to prevent stack overflow
2d609bc resolve merge conflicts of 849c5c7 to mnc-dev
dcc1383 wifinative jni: check array length to prevent stack overflow
project hardware/qcom/audio/
4d27f38 Fix potential NULL dereference in Visualizer effect
916d7d9 Fix potential NULL dereference in Visualizer effect
22da7bf Fix potential NULL dereference in Visualizer effect
project hardware/qcom/media/
59cdda6 mm-video-v4l2: vdec: Disallow changing buffer modes/counts on allocated ports
24afa4e mm-video-v4l2: vdec: Disallow input usebuffer for secure case
51412be mm-video-v4l2: venc: Disallow changing buffer count/size on allocated port
af8b642 mm-video-v4l2: vdec: Disallow input usebuffer for secure case
6529120 mm-video-v4l2: venc: Disallow changing buffer count/size on allocated port
6e12f81 mm-video-v4l2: vdec: Disallow changing buffer modes/counts on allocated ports
fd3168f mm-video-v4l2: vdec: Disallow input usebuffer for secure case
67244a7 mm-video-v4l2: venc: Disallow changing buffer count/size on allocated port
ade29e4 mm-video-v4l2: vdec: Disallow changing buffer modes/counts on allocated ports
project packages/services/Telephony/
22be15b Unexport OmtpMessageReceiver
933472a Restrict SipProfiles to profiles directory
13c0e64 Unexport OmtpMessageReceiver
f82098d Restrict SipProfiles to profiles directory
893326c Unexport OmtpMessageReceiver
000bc0f Restrict SipProfiles to profiles directory
project system/core/
e92c5a9 Fix out of bound access in libziparchive
391c846 Fix out of bound access in libziparchive
9c3f39f Fix out of bound access in libziparchive
This thread is for the fortunate subset of 5th Gen Fire devices that are rooted and rocking a custom ROM. It should also work on rooted FireOS (5.3.1 and below) that have both ads and OTA updates blocked.
There have been numerous posts regarding uneven performance while multitasking along with sluggish response after waking the device from a long slumber. Most recognize this is due to excessive swapping associated with limited user addressable RAM. While there are a number of incremental 'tweaks' that can marginally improve this behavior my objective was to realize a more substantial improvement with minimal effort, knob turning and side effects. To date I have realized the benefit (minimal lag; responsiveness approaching devices with twice the RAM; woohoo!) but still working on the automation that will make it largely transparent. Lacking the time to work on the latter I thought it best to toss out the high level config and let others, if interested, work through both validation and implementation details.
As an aside, I have used the same technique on a 2nd gen HD running CM 11 that had been shelved for many months due to the same issues. It now hums along at a respectable pace and is once again a joy to use.
The secret sauce is simple: expand zram space allocation and add a small, secondary swap file in a normally unused location in permanent storage.
Tools (or adb/shell/terminal commands for those with furry chests):
- EX Kernel Manager (EXKM) or other tool/technique that can manage zram parameters (note: I find current builds of Kernel Adiutor too unstable for this work)
- Apps2SD Pro or other tool/technique that can create/manage traditional swap files and swap space priorities
- BusyBox Installer (v1.27.2+) or other tool/technique to insure startup scripts are properly executed
- L Speed (optional) - for ease of implementing a few discretionary performance tweaks
- DiskInfo PRO (optional) - visualize partition utilization
- RAM Truth (optional) - simple app to visualize RAM utilization
Technique (highly abbreviated):
- boot device to rooted ROM; install above tools or equivalents
- use EXKM to resize zram to 128 MB (note: zram must be temporarily disabled)
- use Apps2SD to:
* add a static, 128 MB swap file in the cache partition which remains largely unused with custom ROMs
* important: reassign swap file priorities (button at top right): 0 for the static file; 1 for zram
* increase swappiness to 100 if necessary (EXKM can also be used to set swappiness and other VM parameters)
* verify both swap spaces are enabled via sliders
Note to geeks: I understand how swappiness, vcache pressure and other virtual memory tunings really work; let's not debate that here. Same with the merits of running a static swap file in combination with zram or the 'dangers' of placing that file in the volatile cache partition. We're talking a hand held device with very modest resources...not the server room with a 99.9x SLA. Yes, zswap would be better. However ...
Optional tweaks:
- use EXKM or L Speed to set LMK parameters to: 24, 32, 40, 48, 56, 64
- use EXKM or L Speed to set write deferral (aka 'laptop mode') to 5 sec
- toggle KSM off/on in L Speed (sets performance enhancing parameters)
- with zram disabled enable zram tweak in L Speed which will establish a 96 MB space along with other optimizations; I find the smaller size ideal for my workflow; YMMV zRAM size can be set with EXKM or another kernel manager.
Challenges:
While the options exist none of the tools noted above can reestablish custom zram space or automatically create a static swap file on boot. I believe this is a kernel issue but have not ruled out interference by Lineage 12.1 which is the ROM I have been testing with. Unfortunately, I lack the time (and quite frankly motivation) to toss Nexus or another ROM on to a spare device to verify the culprit. I might do a bit more testing my my HD 7 which uses a different kernel and ROM. --> Turns out an old version of BusyBox was the culprit; updating to 1.27.2 solved the problem allowing the suggested configuration to be automatically reestablished on reboot. I added my favorite BusyBox installer to the prerequisite tools.
Another issue is the potential for maintaining 'stale' annon pages in zram for a period of time but that's a left field item that probably won't effect most users. A quick fix is occasionally swiping away all apps.
Provide discussion/feedback in this thread. I may or may not respond depending on available time. I love a deep dive (shared above) but once the goal has been reached my interests move elsewhere.
Edit: struck-out references to L Speed after developer/maintainer acknowledged "cooperation" with Kingo Root team (borderline malware).
Quick follow-up: I continue to enjoy benefits noted in the OP with a dual cache configuration. Device remains responsive after waking and typically returns to 'full' performance within a few seconds. I can easily switch between a handful of apps (browser, mail, Play Store, XDA labs, etc) with minimal lag and context preservation; no reloading web pages after switching away. No notable impact on battery life. Really no disadvantages at all - at least with my work flows.
Regardless of tuning one has to keep in mind the modest hardware resources on Fire 7s. Load up a game or two or a couple heavy Amazon/Google apps and things go south pretty quick. That said, responsiveness far better than any stock config, even when the device is clearly overburdened.
Another quick note. Simply adding a classic swap file (suggest 128 GB) to the largely unused cache partition can yield a decent improvement in multi-tasking performance without the complexity of tinkering with zRAM. All steps can be accomplished with the free tool Apps2SD or equivalent. Happy to document if there is sufficient interest.
Note: Be sure to change zRAM swap priority to "1" so it receives preferential treatment over the classic swap file. zRAM will almost always be faster than classic swap but there is only so much if it. The swap file will be used once zRAM is fully utilized (not entirely accurate but generally true).
FWIW - depreciated references to L Speed app in OP after developer acknowledged "cooperation" with Kingo Root team. While nefarious behavior is unlikely there are other options that avoid any potential conflict of interest.
Davey126 said:
...
Technique (highly abbreviated):
- boot device to rooted ROM; install above tools or equivalents
- use EXKM to resize zram to 128 MB (note: zram must be temporarily disabled)
- use Apps2SD to:
* add a static, 128 MB swap file in the cache partition which remains largely unused with custom ROMs
* important: reassign swap file priorities (button at top right): 0 for the static file; 1 for zram
* increase swappiness to 100 if necessary (EXKM can also be used to set swappiness and other VM parameters)
* verify both swap spaces are enabled via sliders
Note to geeks: I understand how swappiness, vcache pressure and other virtual memory e)
Click to expand...
Click to collapse
When you say Cache partition for the swap file are you referring to "/cache" or the second partition for app2sd?
rjmxtech said:
When you say Cache partition for the swap file are you referring to "/cache" or the second partition for app2sd?
Click to expand...
Click to collapse
"/cache" partition which resides on faster internal storage. Anything on external storage will be significantly slower due to interface limitations.
@Davey126 it has been about a day or two and I can confirm that by following these instructions it has brought new life into my KFFOWI 5th gen. This paired with some L Speed Tweaks (even though you say not to trust them, I opted to use it for a few performance tweaks) and the Lineage ROM from @ggow makes my user experience on the device quite pleasing.
rjmxtech said:
@Davey126 it has been about a day or two and I can confirm that by following these instructions it has brought new life into my KFFOWI 5th gen. This paired with some L Speed Tweaks (even though you say not to trust them, I opted to use it for a few performance tweaks) and the Lineage ROM from @ggow makes my user experience on the device quite pleasing.
Click to expand...
Click to collapse
Thanks for the feedback.
As for L Speed I don't distrust the current developer/maintainer but no longer feel comfortable providing an implicit endorsement. Who you associate with makes a difference IMHO. Each person needs to make their own call. There is no magic in L Speed; it simply offers a convenient UI to various well publicized system 'tweaks' that can be implemented using other tools/techniques.
Davey126 said:
Optional tweaks:
- use EXKM or L Speed to set LKM parameters to: 24, 32, 40, 48, 56, 64
- use EXKM or L Speed to set write deferral (aka 'laptop mode') to 5 sec
- toggle KSM off/on in L Speed (sets performance enhancing parameters)
- with zram disabled enable zram tweak in L Speed which will establish a 96 MB space along with other optimizations; I find the smaller size ideal for my workflow; YMMV zRAM size can be set with EXKM or another kernel manager.
Click to expand...
Click to collapse
Thanks for the guide, it already seems to have helped a lot with smoothness but I wanted to know how to set these options using EXKM.
I'd never heard of the app before today and I've had a good look through the menus but can't seem to find somewhere to set these values. I'm guessing these are the usage % values used by the CPU governor to jump up and down power states?
NeuromancerInc said:
Thanks for the guide, it already seems to have helped a lot with smoothness but I wanted to know how to set these options using EXKM.
I'd never heard of the app before today and I've had a good look through the menus but can't seem to find somewhere to set these values. I'm guessing these are the usage % values used by the CPU governor to jump up and down power states?
Click to expand...
Click to collapse
No, governor tunning is a different beast not addressed in the OP (although I do that on some higher end devices).
With regard to EXKM:
- LMK values can be set under memory -> low memory killer
- KSM toggle can also be found in the memory section
- it appears laptop mode can not be set in EXKM (not that important)
As an alternative to laptop mode you can twiddle 'dirty ratio' and 'dirty background ratio' in EXKM. Suggest setting to 30 and 15, respectfully.
Edit: you may also want to take a peek at Kernel Adiutor (correct spelling). While I find it a bit flaky it exposes more controls vs EKKM and costs less too.
Davey126 said:
No, governor tunning is a different beast not addressed in the OP (although I do that on some higher end devices).
With regard to EXKM:
- LMK values can be set under memory -> low memory killer
- KSM toggle can also be found in the memory section
- it appears laptop mode can not be set in EXKM (not that important)
As an alternative to laptop mode you can twiddle 'dirty ratio' and 'dirty background ratio' in EXKM. Suggest setting to 30 and 15, respectfully.
Edit: you may also want to take a peek at Kernel Adiutor (correct spelling). While I find it a bit flaky it exposes more controls vs EKKM and costs less too.
Click to expand...
Click to collapse
Ah, LMK, not LKM. Thanks again.
Also, just a small suggestion but wouldn't it be better to remove the references to L-Speed and leave an edit message at the bottom rather than having the red, striked through text in the middle?
NeuromancerInc said:
Ah, LMK, not LKM. Thanks again.
Also, just a small suggestion but wouldn't it be better to remove the references to L-Speed and leave an edit message at the bottom rather than having the red, striked through text in the middle?
Click to expand...
Click to collapse
Thanks for noting LKM/LMK typo in OP - fixed that.
I will likely clean-up the OP at some point as there are other refinements (eg: tweaking dirty ratios) that may prove beneficial to a larger community.
Davey126 said:
Thanks for noting LKM/LMK typo in OP - fixed that.
I will likely clean-up the OP at some point as there are other refinements (eg: tweaking dirty ratios) that may prove beneficial to a larger community.
Click to expand...
Click to collapse
I was wondering what differences need to be made for a 7th gen hd 10. I know this guide is written for a 5th gen (1gig RAM, 8 gig drive), but I have a 7th Gen (2gig RAM, 32GIG drive) with 2gig zram (priority 1) and 4 gig swap on the /data partition (priority 2). What would be the best LMK values? Also, is it ok to have the swap on /data vs /cache (my /cache only has 400mb)?
Thanks for any help!
edit: in the OP, it says to set laptop mode using L-speed, and then L-speed is crossed out (I understood why), but no alternative is listed for doing this. I just wanted to add that you can use kernel adiutor to change laptop mode. It's on virtual memory settings.
mistermojorizin said:
I was wondering what differences need to be made for a 7th gen hd 10. I know this guide is written for a 5th gen (1gig RAM, 8 gig drive), but I have a 7th Gen (2gig RAM, 32GIG drive) with 2gig zram (priority 1) and 4 gig swap on the /data partition (priority 2). What would be the best LMK values? Also, is it ok to have the swap on /data vs /cache (my /cache only has 400mb)?
Thanks for any help!
edit: in the OP, it says to set laptop mode using L-speed, and then L-speed is crossed out (I understood why), but no alternative is listed for doing this. I just wanted to add that you can use kernel adiutor to change laptop mode. It's on virtual memory settings.
Click to expand...
Click to collapse
It appears you have priorities reversed. Higher values receive preference. The magnitude of the difference is irrelevant. zRAM is considerably faster than eMMC based storage; the latter should only be used when zRAM is exhausted or momentarily unavailable for whatever reason.
The container sizes also seem excessive. 2 GB of zRAM effectively leaves no uncompressed memory on a HD 10 which is highly inefficient. I wouldn't go over ¼ available RAM or ~½ GB. Toss in a 500 MB of eMMC based (overflow) swap file and you're good to go. If you regularly use more than 1 GB of swap on a relatively low end Android device then something else is amiss.
I am aware Kernel Adiutor can set laptop mode but did not want to introduce another tool into the mix...especially one that has demonstrated inconsistent behavior. FWIW - recent testing suggests 1-2 sec may be a better choice vs the 5 sec mentioned in the OP as the latter may trigger lockouts during sustained writes (eg: large file download on a fast connection). I currently use 1 sec and happy with the results. I will likely update the OP with this info once satisfied that the benefit is worth the effort.
All things being equal I see no reason to change LMK values suggested in the OP. Especially given the availability of zRAM and swap.
Thanks for these instructions, Davey126!
I just tried this process on my 5th Gen Fire 7" which I recently installed with the LineageOS ROM. I was not familiar with the EX Kernel Manager and Apps2D Pro tools, but it was reasonably clear how to make the settings changes you recommend.
I added the 128Mb swap under /cache and increased the zram swap to 128Mb, setting it to priority 1. Maybe it's my imagination but my device does seem a lot snappier when switching between running applications, and better at returning to previously displayed data in applications instead of reloading pages.
Cheers!
Matrey_Moxley said:
Thanks for these instructions, Davey126!
I just tried this process on my 5th Gen Fire 7" which I recently installed with the LineageOS ROM. I was not familiar with the EX Kernel Manager and Apps2D Pro tools, but it was reasonably clear how to make the settings changes you recommend.
I added the 128Mb swap under /cache and increased the zram swap to 128Mb, setting it to priority 1. Maybe it's my imagination but my device does seem a lot snappier when switching between running applications, and better at returning to previously displayed data in applications instead of reloading pages.
Cheers!
Click to expand...
Click to collapse
Thanks for sharing first impressions. Time will tell if the benefits are durable; certainly have been for me with no adverse side-effects.
Another suggestion to reduce wake lag: install Greenify (or similar tool) and add commonly used apps to the action list even if not flagged as background abusers (you may need to override Greenify's sensible defaults via the gear icon). This prevents multiple apps from becoming simultaneously 'active' on wake which is a huge contributor to lag on lower end devices with limited resources (CPU and RAM). Hibernated apps will launch when needed with minimal delay and NO loss of context. Works a treat.
Be sure to add your favoriate browser, mail, messaging and social media apps to the hibernation list as all like to 'check in' after a long slumber.
Although Greenify can auto-hibernate apps on most devices (works best with Xposed Framework) I use an automated approach that invokes Greenify's widget when the screen goes off. There's still some momentary lag on wake but the device remains responsive which is a huge improvement.
Hi Davey126,
thx for the guide, it seems to work awesome.
However, i have the one problem thats the settings in EXKM regarding to "zRAM Size", "dirty ratio" and "dirty background ratio" are lost after rebooting the device. Is there a way to make the settings reboot proof? Interestingly for the "LKM" settings there is an option "Apply at bootime", which does the trick for me, but only for the LKM options.
Kind regards,
Stephan
IronMan1977777 said:
Hi Davey126,
thx for the guide, it seems to work awesome.
However, i have the one problem thats the settings in EXKM regarding to "zRAM Size", "dirty ratio" and "dirty background ratio" are lost after rebooting the device. Is there a way to make the settings reboot proof? Interestingly for the "LKM" settings there is an option "Apply at bootime", which does the trick for me, but only for the LKM options.
Kind regards,
Stephan
Click to expand...
Click to collapse
Likely BusyBox is missing or outdated. Try installing this (I use the pro version).
Davey126 said:
Likely BusyBox is missing or outdated. Try installing this (I use the pro version).
Click to expand...
Click to collapse
Ok. I bought BusyBox Pro and updated to Version 1.28.1-Stericson. Still all settings in EXKM besides LMK get lost after rebooting the device ...
IronMan1977777 said:
Ok. I bought BusyBox Pro and updated to Version 1.28.1-Stericson. Still all settings in EXKM besides LMK get lost after rebooting the device ...
Click to expand...
Click to collapse
- verify BusyBox is property installed w/no conflicting builds
- uninstall/reinstall EXKM
- test if behavior can be duplicated with another (free) kernel manager like KA
Hello owners of Samsung Galaxy Tab S 10.5 WiFi (chagallwifi) SM-800,
Let's save some more devices from the garbage. Here is a build for LineageOS 17.1 for SM-T800 (tested only on this device).
Tested and working so far
Wifi.
Camera (front and back).
Location.
Touchscreen.
All other sensors.
I am not aware of anything broken.
This is a plain build of LineageOS 17.1, with only minimal SELinux policy modifications to make the device work.
If you prefer to use OpenGApps, download signed-ota_update-plain.zip, if you care more about privacy and prefer a degoogled version, download signed-ota_update-microg.zip which has microG bundled in it.
Special thanks to owners of:
LineageOS: https://github.com/LineageOS
Exynos5420: https://github.com/exynos5420
Kernel source.
microG: https://github.com/microg
Guide to building LineageOS with microG: https://gist.github.com/dic1911/407184ee427c50ad0066af643a20254f
microG Mobile Services: https://github.com/lineageos4microg/android_vendor_partner_gms
You are welcome
Great news, thanks!
Could you please clarify what you wrote about SELinux? Is it active and enforcing? Is encryption supported?
porcino said:
Great news, thanks!
Could you please clarify what you wrote about SELinux? Is it active and enforcing? Is encryption supported?
Click to expand...
Click to collapse
SELinux is active and enforcing, the modifications are because the default SELinux policies in LineageOS contradict with those of the device (probably because the device ones are few years old). The modifications are to remove some strict policies that would break device drivers like the camera and sensors if left enabled.
Encryption is disabled.
minashokry said:
SELinux is active and enforcing, the modifications are because the default SELinux policies in LineageOS contradict with those of the device (probably because the device ones are few years old). The modifications are to remove some strict policies that would break device drivers like the camera and sensors if left enabled.
Encryption is disabled.
Click to expand...
Click to collapse
It's great that SELinux is on, and it is expected to have minor cuts in the policies. They are a pain to develop. It has to be a separate project...
What's going on with encryption? Forgive me for a silly question, I just see this feature missing in LOS17 ROMs for other devices as well... Is it something LOS specific?
porcino said:
It's great that SELinux is on, and it is expected to have minor cuts in the policies. They are a pain to develop. It has to be a separate project...
What's going on with encryption? Forgive me for a silly question, I just see this feature missing in LOS17 ROMs for other devices as well... Is it something LOS specific?
Click to expand...
Click to collapse
Honestly I don't know about encryption. I didn't care about it while building this image.
minashokry said:
Honestly I don't know about encryption. I didn't care about it while building this image.
Click to expand...
Click to collapse
Fair point - it has to be running at all before looking at the advanced features. For the first release it's quite a remarkable result. It would be nice to have encryption on the to do list...
Another silly question: the speakers of this tablet are not very loud. Is it difficult/possible to boost their volume a little?
Will test this out. I had flashed LOS17.1 by @8224Freak, but its SELinux is disabled. Will see if this one works same or better. Does this build contains the most recent security patch?
@minashokry thanks for the build. Camera only works with picture taking. It freezes when video recording is ended.
@minashokry I have been using your build on my T800 and likes it a lot. In addition to the camera video recording freeze, mic does not appear to work well. I tried some audio recordings but only hear tiny sound during playback. I was wondering if you are planning on updating the build once awhile to at least include new security patch., or this is it - no more update? Thanks again for build this smooth LOS17 rom for the old tablet.
foolone said:
@minashokry I have been using your build on my T800 and likes it a lot. In addition to the camera video recording freeze, mic does not appear to work well. I tried some audio recordings but only hear tiny sound during playback. I was wondering if you are planning on updating the build once awhile to at least include new security patch., or this is it - no more update? Thanks again for build this smooth LOS17 rom for the old tablet.
Click to expand...
Click to collapse
Bump
Unfortunately did not get very far using either of these builds (plain or microG). In both cases, I'm unable to read or write to the internal storage on the tablet. File manager does not read any contents of the internal storage, fails to create a directory in internal storage, and can't download/save a file from the internet. The LOS 17.1 by @8224Freak does not have this problem, so assume it's something unique to these builds.
I also found that when I formatted an SD card for use as tablet storage (i.e., as an extension of the internal storage), it insists that the card is not inserted every time I power on the tablet. If I eject and reinsert the card while still powered on (no power cycle) it recognizes it and is okay from there.
Don't know if this is related to the above, but the native camera app insists that I must "Insert an SD card before using the camera" even though an SD card is plainly inserted and recognized by the rest of the system.
minashokry said:
Honestly I don't know about encryption. I didn't care about it while building this image.
Click to expand...
Click to collapse
Hello. I've tested your ROM just out of curiosity -- encryption works! This makes your ROM the leader in security! Well done, thanks!
Apart from this... I found a fault with video rendering. At some resolutions the video renders at a wrong scale, larger than the window or the screen. This happens with different websites. I am using Brave browser, which works fine on the same device with LOS-14.1. The same rendering problem is evident in the other LOS-17.1 ROM as well (by 8224Freak). It might be codec related.
Has anyone found a way of dealing with the video rendering fault in Brave/Chrome/Firefox?
What is the link to download this rom? I can't find it anywhere in this thread.
mmaazzaa said:
What is the link to download this rom? I can't find it anywhere in this thread.
Click to expand...
Click to collapse
Use the attachments to the first post "signed-ota...zip".
Thank you. Due to the file name I mistakenly thought it was just an update for the rom, not the rom itself.
Tried this ROM again (signed-ota_update-plain.zip), different screen resolutions, different screen densities - still video playback issues in browsers including Brave. The fault manifests itself as the video being zoomed in, so that only a part of it remains visible. The playback freezes for a fraction of a second occasionally, producing a "metal" screeching sound while doing it. In general this ROM feels a bit laggy. So, going back to lineage-14.1-20220107-UNOFFICIAL-chagallwifi, which feels cleaner, much faster and similar to this one has SELinux+encryption working.
Before anyone asked, the same video playback issues just without freezing I observed in lineage-17.1-20220504-UNOFFICIAL-chagallwifi, which is under active development now. The latter does not have SELinux+encryption though.
So, for now, the benchmark is set by DarkExistence for this device.
[ROM][7.1.2][UNOFFICIAL] LineageOS 14.1 - SM-T800
LineageOS is a free, community built, aftermarket firmware distribution of Android 7.1.2 (Nougat), which is designed to increase performance and reliability over stock Android for your device. #include /* * Your...
forum.xda-developers.com
Just tried this rom, I'm pretty sure the hitching and video playback issues are because the gpu is sitting at 0% utilisation so it's using the cpu for rendering... which would explain things
I downloaded and installed "signed-ota_update-plain.zip". But Google account is not added. There is no Google Play. Thank you to those who will help.
I installed Gapps and OK.
ahmetdamar said:
I downloaded and installed "signed-ota_update-plain.zip". But Google account is not added. There is no Google Play. Thank you to those who will help.
Click to expand...
Click to collapse
Did you install Gapps or its equivalents?