[Motorola Droid 4] Septfox:
Hotplugging is turned on by default; it's been known to cause stability issues on some chips. If you're on the very edge of "enough" voltage using the LV kernel, the instability that hotplugging can add might tip it over the edge. Try disabling it in Kernel Aduitor or the like and see if you can get by. If not, looks like it's HV kernel for you.

Yes, even if some of said other people shouldn't be skimming things at 3 in the morning and failing at reading comprehension... *cough*

My face sure does feel eggy.

Quite.

It doesn't look like we can outright disable min_free_kbytes, but in my case swapping it and extra_free_kbytes (for 4mb/32mb respectively) has certainly improved in-app fluidity and to an extent reduced the amount of UI freezing. I wouldn't go so far as to say it feels like a new phone, but it's a marked difference.

I played with it out of curiosity; it looks like around 130mb or so is the cutoff with extra_free_kbytes increased. Below that starts hitting excessive slowdowns again...it looks like this is helping the problem more than anything else has, but it's still not the problem.

I managed to get it below 90mb free and still maintain (some) responsiveness, but even with very passive minfree settings couldn't get it to go lower, probably due to certain caches and buffers reporting as reclaimable but not actually being so.

Then the free memory went back up to ~100mb as something was apparently cleared that shouldn't have been, and phone started soft-freezing until I rebooted it. So uh...we're definitely still limited.

Stock minfree settings seem a touch too low for optimal performance, particular Hidden and Content Providers. I've increased mine to 135/150 respectively, and it looks to be good.

That part, I didn't miss. They're talking about triple-buffering for the UI, to try and keep it from becoming janky. I'm talking about the 3D performance issues that have plagued some of us since January or so; specifically very "laggy"-feeling, shuttery rendering that comes and goes for no apparent reason, yet doesn't show up on benchmarking. Nothing in the commit log between mid-December and mid-January seems to indicate what went wrong.

I immediately made the connection you did, though, when I was messing with min_free_kbytes...which prompted me to reduce it to 1mb and dump some heavy memory pressure onto the phone. It continued running fine, at least as far as pure 3D performance went.

It might be related, and probably is, but I'm not really convinced.

The processor doesn't have the throughput to run certain tasks without saturating for several seconds at a time. A lot of trouble with usability up until now has been memory issues, but the next thing on the list is the CPU frequently maxing out.

"Unsuitable" was admittedly a little too strong a word. It does run it pretty well, considering we're talking about an O/S that's two full generations newer than the phone was intended to run, itself using a 2011 processor. But we'd be much better off if Motorola had decided to use a Qualcomm SoC (as they did in the PhotonQ), or even their then-current OMAP4 4460, not stuck us with the previous-generation 4430.

*shrugs*

Unfortunately, I don't think it's a simple task at all to backport all of the changes, or someone would have done it by now. stargo's not the only one with interest in the OMAP4.