yashsingh1/xdaforums huggingface dataset:
[Motorola Droid 4] u.b.o.o.t:
I don't mind, and I really appreciate other people helping to tune / improve the current situation because the only alternative to the Droid4 would be the Photon Q with SIM-mod, which is hard to get these days (wish I'd bought it when there was a bunch of modded like-new devices on ebay) :)

page-cluster's default on the Droid4 is 0. Tried 3 (aka 2^3=8) but didn't make a difference. Higher values make sense for swap devices with slow random access (aka plain old magnetic hdd). Setting it to zero is proposed for flash and zram swap.

overcommit_ratio is pretty harmless (opposed to overcommit_memory of course), but you're right - there is no sense in modding it.

But I'm in doubt about min_free_kbytes - it is said to trigger OOM killer (which is the kernels last resort, way more evil than LMK) if set too high.

extra_free_kbytes was hinted in the PDF I linked above and according to the docs, it prevents kswapd direct reclaim which definitely causes UI freeze.

You'll also find it mentioned in https://source.android.com/devices/tech/config/low-ram.html

extra_free_kbytes is not present in official google 3.0 kernel, it was backported from 3.4 kernel to the Droid4:

https://android.googlesource.com/kernel/common/+/deprecated/android-3.0/Documentation/sysctl/vm.txt

https://github.com/CyanogenMod/andr...mmit/9b54e660c8084249514d90206e9db88ca6ef32ff

It seems unbelievable, but I don't have any choking below 180MB anymore... My phone runs at 130..140MB free memory since a while and switching between recently used apps is quite instant. Lags still occure when firing up non-cached or swapped apps, but this doesn't freeze UI anymore and swapping in an app is still faster than reloading/initializing an app. In the past, I was unable to drag down status bar notifications in such a case and sometimes I was even unable to unlock the phone because the lock screen UI frooze for like 5 seconds and the screen turned black before UI input was processed... o_O

Regarding your 3D performance improvement - just read the PDF I mentioned ;) It says that there always has to be enough free memory for graphics buffers for a fluid UX and this is why extra_free_kbytes was introduced. With min_free_kbytes you get a similar effect but I'm afraid that you'll get undesired side effects also (OOM, crashes).

EDIT: Just a side note:

The CPU is a Cortex-A9 dual core which is more than sufficient IMO to run Android 6. My 2012 Xperia Pro was only single-core and also runs CM13 quite snappy and with only 512MB is is even snappier than the Droid4 (with extra_free_kbytes at stock value of 6075)! The biggest issue with the Droid4 IMO is: outdated kernel! This keeps us back from F2FS support and certain improvements to memory management Google introduced with 3.4 and later.
[Motorola Droid 4] Flash-A-Holic:
Crash at WakeUp

So I rushed to test OC kernels with my Droid 4. First I tried Run 'N Gun Kernel ULV @1.4Ghz and it was performing very well. Only

massive downside

was that when I leaved my phone for while to desk (screen goes off) and then tried to wake it up, it crashed. Same situation with Full Scale 1.4Ghz Kernel ULV and LV. I tried to set min freq to 400Mhz but it didn't help.

Well everyting is working now with Full Scale 1.4Ghz Kernel HV (1.4Ghz-300Mhz). I'm just wondering that is that kind of issue common with Droid 4 OC kernels? Or can I use ULV or LV kernels with tweaking Governors, Schedulers etc.?

Great work Devs! :good:
[Motorola Droid 4] u.b.o.o.t:
[MENTION=6812457]Flash-A-Holic[/MENTION]: I also had crashes at least once a day with ULV kernel and latest CM13 nightly. But with a nightly from around the date, the ULV kernel was built, I had no crashes. Maybe, [MENTION=1070688]joojoobee666[/MENTION]'s kernel just needs to be rebuilt...
[Motorola Droid 4] joojoobee666:
Crashes typically occur due to the the sensitivity of the SOC. Some take the overclocking much better. The HV is the high voltage which helps stabilize, but some SOC's just won't take the 1.4 very well. If it doesn't stay stable, you may just want to use one of the 1.3s.

I can rebuild but I don't see how it will help as the kernel has not had any changes so it will basically be no different. The kernel is in many ways quite separate from the actual CM13 code. If you are experiencing issues with the ULV (Ultra Low Voltage and this one is extremely picky with the SOC), try one with higher voltage.:good:
[Motorola Droid 4] Septfox:
[MENTION=309785]u.b.o.o.t[/MENTION]

Remember when I was all

Well, ignore that and if you haven't already, try some seemingly absurd high values like 128mb, 192mb, 256mb. I need to know if I'm crazy or going stupid-high amounts is improving multitasking capability as much as it seems.

Seriously, I have Alphabear, Ingress and the Play Store currently running and fast-switchable, and after the initial splash screen Pokemon Go loads fast without the usual multiple ANRs from Play Services and Store (for the Location Service and In-App Billing respectively). I can also switch out of Go and fairly quickly load up other things - even heavy things such as Maps - without it immediately getting dumped out of memory. In-app performance has also smoothed somewhat more.

All this on the "stock" minfree settings, min_free_kbytes=2mb, extra_free_kbytes=256mb (262144), choking less than normal min/free_kbytes did even with more aggressive minfree settings.

Oh, and as a minor aside...swap usage intensifies. Just a little bit.

Haven't tried setting higher minfree limits again, I imagine some of the remaining slowness will be alleviated by increasing them. All this swap is doing fun things with reported memory usage, though, so the minfree limits don't seem to be working quite as expected.

(and the task manager/app switcher/whatever reports ~100mb above this)

Seems that indeed, swap is the way to go, and you found how to make it work more or less properly. Congratulations on the find.
[Motorola Droid 4] u.b.o.o.t:
I'm glad that you're having success with extra_free_kbytes, too!

At least, we have a workaround now.... until someone manages to cure lowmemorykiller.

I'm really not convinced that the cpu is the main bottleneck here because I'm facing many lags with the cpu not fully utilized (running at 300..600MHz only) while there is lot's of I/O activity.

You can verify this with the following app which can be configured to permanently show on-screen info like cpu load, cpu freq, I/O throughput, etc: https://play.google.com/store/apps/details?id=ds.cpuoverlay

Also, try to have "vmstat 1" running via ADB shell while poking around with different apps. The last column shows i/o wait time, i.e. when cpu is waiting for i/o operations to finish. This could be caused by slow flash.

Regarding Omap4 - the only difference between 4430 and 4460 is clock speed. Architecture, cache, mem bandwidth - all the same.

But there seems to be some notable work going on for Galaxy Tab 2, Nexus & friends: people managed to add dynamic memory allocation for buffers needed for camera & video en/decoding stuff, which bumped max. RAM available to the system from 696MB to 994MB. Well, the Droid4 is already at 839MB, but 150MB more would surely help....

Also, these peope seem to put lot's of effort in kernel backports: https://github.com/OMAP4-AOSP/android_kernel_omap4_common

I wounder if that makes it easier to improve our kernel...
[Motorola Droid 4] Flash-A-Holic:
Tweaking

[MENTION=309785]u.b.o.o.t[/MENTION]

[MENTION=5521404]Septfox[/MENTION]

Great research guys! I really appreciate your work :good:. I have tried to read and understand everything you have written (in fact read the whole thread today) but it's hard to catch up. Could you guys write small tutorial or you "own view" what you have done so far. I can see some lag with my Droid 4 (not bad) but if there is some tweaking to do I want to try and test :p
[Motorola Droid 4] Bobcus Leper:
Its funny that you mention OMAP-4 AOSP. I was just going to ask [MENTION=3457922]stargo[/MENTION] if he knew about the project. The extra RAM certainly could help relieve some pressure.
[Motorola Droid 4] u.b.o.o.t:
just install https://play.google.com/store/apps/details?id=com.grarak.kerneladiutor and increase extra_free_kbytes to 50000 (virtual memory settings) and low memory killer: agressive profile.

---------- Post added at 07:48 AM ---------- Previous post was at 07:43 AM ----------

He does ;) https://omap4-aosp.github.io/team.html But I'm afraid he doesn't have much spare time these days...
[Motorola Droid 4] Flash-A-Holic:
Already tried that. I can activate virtual memory and set profiles etc. but when I tried to change values (for example extra_free_kbytes) Kernel Adiutor will crash. Root is working good and busybox installed. Already tried to re-install Kernel Adiutor but it didn't help. Here is logcat. You can see force close on line 526

09-09 11:47:24.202 526 1059 W ActivityManager: Force finishing activity com.grarak.kerneladiutor/.activities.NavigationActivity
[Motorola Droid 4] Bobcus Leper:
I'm using the beta version of kernel auditor, and I can set the memory values without issues. You can sign up to beta test on Google Play.
[Motorola Droid 4] Flash-A-Holic:
I got the Kernel Adiutor working by changing to Kernel Adiutor-Mod. I can confirm that setting high values to extra_free_kbytes Droid 4 responds faster :good:.
[Motorola Droid 4] u.b.o.o.t:
For me, extra_free_kbytes = 75000 works best. I never had issues with suspend and watching free memory (I mean: physically free RAM, e.g. as show by free command) these 75MB are instantly consumed when firing up a new app and most of my apps do not need more when getting started.

Regarding IO - I suspect, ZRAM access and other magic is also accounted for.... But I remember my Xperia Pro with Android data partition on external SDcard - a faster card (i.e. one with high random read/write access and properly aligned partitions) signifficanly increased response time and reduced IO wait.

And: according to the docs, kswapd direct reclaim blocks IO, so IO wait may also be caused by that.
[Motorola Droid 4] u.b.o.o.t:
[MENTION=5521404]Septfox[/MENTION]: Loop device overhead - my fear as turned out to be true! Having system & data partitions residing in loop devices results in double-vfs-caching of the data! https://unix.stackexchange.com/questions/278647/overhead-of-using-loop-mounted-images-under-linux

Seems we have to bite the apple and install on stock rom slot... or find a way to install on external sd card partitions...
[Motorola Droid 4] Bobcus Leper:
So will installing to the stock slot fix the double caching, and significantly increase the I/O speeds?

BTW, using privacy guard to keep apps from being able to use background memory, has allowed me to have approximately 550-600 MB of free RAM most of the time. As Septfox said, I still have slow wake up times because of the ZRAM unloading apps while in deep sleep.

[MENTION=309785]u.b.o.o.t[/MENTION] and [MENTION=5521404]Septfox[/MENTION], you two deserve way more credit and likes!

:good:
[Motorola Droid 4] Septfox:
I have a feeling that installing directly to external partitions isn't an option for one reason or another. That said it should be, since it's "just" some partition work and mountpoint shenanigans(?). [MENTION=1070688]joojoobee666[/MENTION], you were messing with mounts to achieve SD-swap, from what you've seen is it possible to mount the SD card early enough to boot off of partitions stored on it? Or alternatively, even if we could do just the userdata partition and put everything else on the onboard physical/stock partitions, that would be a huge boon since CM13 fits into the stock system partition with nano gapps and a bit of shoving.

Looking at the benchmarks in one of the commits linked from that page, probably not a massive increase in I/O, but it should save a small amount of memory from only using one cache vs two. I'd think that R/W latency should also go down slightly and not depend quite so much on CPU/memory I/O load.

Regarding the slow wakes, I haven't tried it yet, but in theory it should be possible to use something like Tasker (assuming it can be triggered by screen on/off) to dynamically raise and lower extra_free_bytes and minfree limits based on the state of the phone.

This way, you can have aggressive swapping while the phone is awake and the better multitasking that comes with it, but set much lower extra_free_bytes and close-to-stock minfree while the screen is off. (Again theoretically) it would effectively halt attempts to free more memory and hopefully keep it from swapping everything out, as well as save a minute amount of power by allowing everything to idle down sooner.

I deserve nothing, all I'm doing is riding on u.b.o.o.t's coattails and demonstrating how not to try and abuse the memory mechanisms :v
[Motorola Droid 4] Septfox:
Double-posting like one of the cool kids.

Using Automate, I've made an automated task that should apply less aggressive minfree and extra_free_kbytes settings with the screen off, and quite aggressive settings with the screen on. Following the theory in the last post, this should help prevent excessive delays in the screen coming back up, assuming the delay is due to systemUI and other needed things being swapped out.

I don't know if it actually does, mind you. The task works and applies the settings as intended, but no idea if it solves the problem yet. The build is below, or you can be lazy like I would be and download the attached .flo flowchart (it's a .h because the forum allows only certain extensions, rename to .flo) and import it into Automate, customize it from there. Note that you'll also at least need the Automate Superuser Permissions module.

Overall chart:

The first When screen On/Off trigger is set to proceed when the screen state changes.

If screen is off, runs a shell command to set minfree limits and then another to set extra_free_kbytes, then loop back to the first screen on/off check

If the screen is on, delay for 5 seconds; this because we don't want to set higher limits too soon if the user is just say, lighting the screen to check notifications...should be set shorter or longer depending on the user

After 5 second delay, check if the screen is on again; this one is set to check and proceed immediately

If screen is still on, run a shell command to set minfree limits and then another to set extra_free_kbytes, then loop back to the first screen on/off check

If screen is off, loop stright back to the first screen on/off check

If the screen is off, these are the shell command blocks that are run. I don't recall specifically what I set the minfree limits to and can't be bothered to maths to find out, but they're lower than stock. extra_free_kbytes is at 8mb.

Also, you could save yourself some keystrokes by setting the working directory and echoing the files directly, but I personally prefer just setting the working directory to root and echoing the entire path for no particular reason.

If the screen is on, these are the shell command blocks that are run, assuming the second screen-on check passes after 5 seconds. The minfree limits translate to megabyte values of 60/75/125/150/170/180. extra_free_kbytes is 256mb.

You'll want to find out your own values and replace them (minfree in pages can be found by doing "cat sys/module/lowmemorykiller/parameters" via terminal/shell or mathing it, as each page is 4kb and a megabyte is 1024kb).

Don't forget to exclude Automate and SuperSU from being affected by Doze (Settings>Battery>Battery Optimization), or (additional) odd things might happen.

Edit: doesn't seem to have helped. Might be that I'm barking up the wrong tree after all.

Could also try reducing swappiness to 0, in case some sort of swap-happy shenanigans are still going on for whatever reason.

echo 0 > proc/sys/vm/swappiness

echo 100 > proc/sys/vm/swappiness

For screen off and on respectively.
[Motorola Droid 4] u.b.o.o.t:
[MENTION=5521404]Septfox[/MENTION]: I really wonder what you are struggling with... looks a bit.... uhm.... lost on the wrong track... :(

My settings are: min_free_kbytes=default, extra_free_kbytes=75000 and lowmemorykiller: kernel adiutor aggressive with empty app at 160MB

I haven't had any lags after resuming from standby.... This only happened in the past - without the extra_free_kbytes-tweak. But I don't have any super-heavy things on my phone like Ingress, Pokemon & friends, nor Facebook nor any Google App except from Playstore. Permanently in RAM there is only Trebuchet, Cool Tool, Pebble, Tasker, Whatsapp, DAVdroid, aCalendar+, Smart Keyboard Pro (veeeery lightweight!) and whatever Android likes to cache.

I mostly have 140...260MB of free memory.

Apart from that, I don't care how much ZRAM is utilized. All that counts for me is responsivity, and this one has greatly improved.
[Motorola Droid 4] Flash-A-Holic:
This is hilarious and helpful example, thanks :good:

If you really had to make that change then Droid Turbo is good choice. Great hardware! SD805 is so many times forgotten. If you are looking for new adventures with Droid 4 then take a look what I have in mind (link). ;)
[Motorola Droid 4] Bobcus Leper:
Hmmm... Sailfish OS. If it is smoother than android, it might be worth porting to Spyder and Targa too.
[Motorola Droid 4] Septfox:
I had to, and I did. And holy crap is it glorious. It just quietly and smoothly hums along, and the screen on it is absolutely absurd.

I've read somewhere that it was going to be the Nexus 6 until someone changed their mind at the very last moment, and if that's true I can believe it.

The bootloader is now unlocked courtesy of SunShine, but...after trying out the ROMs available, I find myself switching back to stock LP. Call me crazy, but I actually like some of the Moto additions and Moto Display...CM doesn't emulate all of them, and the ones it does don't feel quite right.

Well now, that's an interesting idea. I'll be keeping an eye on the thread.
[Motorola Droid 4] u.b.o.o.t:
Hi folks! I had some spare time to setup CM13 build tool chain and - maybe too late for [MENTION=5521404]Septfox[/MENTION] - I made a custom kernel with LMK accounting for swap memory, i.e. LMK does only consider memory pages as free which won't require swapping, now. In order to not spam this thread anymore with LMK issues and memory tuning, I created a new thread: http://xdaforums.com/droid-4/development/wip-custom-kernel-lowmemorykiller-t3470411
[Motorola Droid 4] joojoobee666:
This is cool. :cool: I'll test these out here as well. If things look good I'll see about getting LMK changes added to the cm13 kernel and upcoming cm14 kernels (work just began).:good:
[Motorola Droid 4] Bobcus Leper:
CM14 confirmed?:fingers-crossed::good:
[Motorola Droid 4] joojoobee666:
Not really confirmed (as in no promises it will ever be fully functional as of yet). Just started working on getting things compiling. After that, it's along ways a way from anything usable as there are some new hurdles to overcome thanks to additional lock-downs on SE Linux. So yeah, :fingers-crossed: is right. ;)
[Motorola Droid 4] u.b.o.o.t:
You're welcome :)

I could prepare a patch for you... but I'm about to push a change request for the new lmk to gerrit code review.... but before I'd like to change default LMK watermarks in cyanogenmod source code. Do you know the related source file?
[Motorola Droid 4] joojoobee666:
I'll have to go digging around again to see. I'm thinking it just may be taking the defaults from the framework. I'll have to dig further to see for sure. If so, those can most likely be overridden by a device overlay during compile.
[Motorola Droid 4] chuchipando:
Thats the phone I want, been kind of scared to get it and find out theres no way to unlock the bootloader. I read here on XDA that the firmware needs to be a specific version/s because there is an OTA update that fixes the bootloader unlock exploit. How did you go about purchasing your Droid Turbo? did you have to ask what firmware it was on before purchasing? Thanks. :good:
[Motorola Droid 4] joojoobee666:
Sure, I'll take a patch to play with. :)
[Motorola Droid 4] joojoobee666:
Hey all, new kernels up. Some older patches that I never got around to putting in are now in as well as [MENTION=309785]u.b.o.o.t[/MENTION]'s LMK patches. Thanks again [MENTION=309785]u.b.o.o.t[/MENTION]. :highfive:
[Motorola Droid 4] Bobcus Leper:
Hi,

Thanks [MENTION=309785]u.b.o.o.t[/MENTION] and [MENTION=1070688]joojoobee666[/MENTION] for the kernels and LMK commits. I can actually multitask now. I haven't found a need to change the min free kbytes with the new kernels. I'll see how these new kernels hold up in the next week. :good:
[Motorola Droid 4] joojoobee666:
Hey guys, just posted another small update. Something was not working right on my build script and the libthermal-manager.cfg files were not getting dropped in the zip. This file tells libthermald when to step down the CPU clock based on temp. It's tweaked for my kernel to allow higher temps so it doesn't step down to 1000 so quickly when under high load. It's actually been missing for quite a few of the recent kernel releases. :eek: Anyhow, I finally noticed so it's fixed now.

Also, you will notice that the size increased somewhat. This is due to me adding in the kernel modules found in system/lib/modules. This isn't required but I figured it may be good to force the latest versions to install with the kernel in the event some of you are using an older CM build which wouldn't contain any potential changes to those modules on future releases.:cool:
[Motorola Droid 4] u.b.o.o.t:
Does anyone of you guys have increased battery drain with one of the kernels incorporating my lmk patches?

I'm facing SUSPEND_BACKOFF kernel wakelocks (https://github.com/asksven/BetterBatteryStats-Knowledge-Base/wiki/suspend_backoff) preventing the device from going deep asleep and it seems this occures as soon as Wifi has been switched on and off...

EDIT: it's not my patches' fault... having the same issues with standard cm13 kernel...
[Motorola Droid 4] Septfox:
I've just updated and flashed the modified kernel. It does seem to be generally running better, currently letting it idle a while to see if it too wakelocks. My results might be a bit skewed due to Greenify running, but we'll see.
[Motorola Droid 4] rabinhood:
As I mentioned in the other thread, I found uboot's patch v 2.2 much more responsive than v 2.3 incorporated in this kernel.
[Motorola Droid 4] joojoobee666:
Hey all, I updated the kernel today to use the LMK 2.2 configuration. Check the first post for all the goodies. :good:
[Motorola Droid 4] joojoobee666:
One more update today. This has the 2 new security patches from the mainline.:cool:
[Motorola Droid 4] RikuKawai:
SELinux permissive 1.3GHz

Can you build an SELinux permissive version of FullScale Lite (1.3GHz)?

I need SELinux in permissive mode, but my phone won't boot properly at 1.4GHz.

Thanks.
[Motorola Droid 4] joojoobee666:
Here ya go. Let me know if it's working correctly. If so, I'll make sure it gets added to the normal rotation. :cool:
[Motorola Droid 4] RikuKawai:
Yes! It seems to be working so far.

The problem I was having is the SELinux Enforcing kernel delays the launching of my init.d scripts, so apps linked to a second partition didn't show up.

Edit: My phone just did a soft-reboot while I was typing this, might not be working so well after all. Will investigate if it's the kernel alone or a combination of things causing it.

Edit 2: Did a full reboot to make WiFi work again and it seems to be running stable now, must have been an isolated and random crash; potentially a CyanogenMod bug and not related to the kernel at all.
[Motorola Droid 4] moodroid:
Hi,

I haven't a clue about this, but just wondered if this dirty cow thing applies to these kernels?

Thanks
[Motorola Droid 4] u.b.o.o.t:
It does! And it has just been fixed by [MENTION=1070688]joojoobee666[/MENTION] :D Just wait for a new kernel or nightly being built...

https://github.com/CyanogenMod/andr...mmit/21b6345c53be779f8aae268e6a3279a1c05e1b6d
[Motorola Droid 4] moodroid:
Excellent, thanks. Should have know you guys would have it under control. Thanks, JJB and thanks, u.b.o.o.t. :)