[Motorola Droid 4] Septfox:
Man, I hope you guys like walls of text.

You're right, of course. I had it in my head that things like loading apps would be buffered sequential reads, but since we have a flash device, and the Linux mindset seems to be "nah, we don't need defragmentation, just let the filesystem handle it", stuff's probably scattered all over the media.

...wonder if I can manually run a fsck on /data/ via Safestrap to see if this is actually a problem.

I actually decreased extra_free_kbytes to 4096, and increased min_free_kbytes (first to 32mb, then 16mb.)

There does seem to be some improvement when setting it higher. Information on it here: http://stackoverflow.com/questions/21374491/vm-min-free-kbytes-why-keep-minimum-reserved-memory, the gist seems to be that it's memory set aside for immediate use by various things - including LMK and swap work. I would suppose it might decrease the choking that happens under 180mb free, since the memory-freeing mechanisms among other things aren't having to fight userspace apps for working room. Haven't tried going for super-low settings yet to see, though.

Keep in mind that it's reserved memory, so apps shouldn't be able to use it. 32-35mb is probably more than a bit too high...but that's actually what I started with, and saw no ill effects aside from less apparently freeable memory. Probably just swapped more stuff out to make up for it.

Don't worry, I'm sure it'll still soft-lock and eventually reboot if you set your minfree amounts too low :>

The amount of "extra" memory it can offer is indeed a bit ridiculous; I've gotten it to page as much as 450mb under heavy pressure...probably ran out of physical memory for the swap to use at that point, or there was simply no more that was swappable. Forgot to look.

I've been messing with some of the VM settings the last couple days. There are a few that have stuck out:

page-cluster: Kernel Aduitor doesn't expose this setting. Default is 0 for our configuration.

page-cluster

page-cluster controls the number of pages up to which consecutive pages

are read in from swap in a single attempt. This is the swap counterpart

to page cache readahead.

The mentioned consecutivity is not in terms of virtual/physical addresses,

but consecutive on swap space - that means they were swapped out together.

It is a logarithmic value - setting it to zero means "1 page", setting

it to 1 means "2 pages", setting it to 2 means "4 pages", etc.

Zero disables swap readahead completely.

The default value is three (eight pages at a time). There may be some

small benefits in tuning this to a different value if your workload is

swap-intensive.

Lower values mean lower latencies for initial faults, but at the same time

extra faults and I/O delays for following faults if they would have been part of

that consecutive pages readahead would have brought in.

Since we're swap-heavy, increasing it to at least the Linux default might increase efficiency slightly. My messing with it was inconclusive.

I also like how the documentation says 0=1 page, but a few lines later says that 0=disabled. Brilliant.

vfs_cache_pressure: mentioned in a post in the CM12 thread, if I recall right. Defaults to 100.

vfs_cache_pressure

------------------

This percentage value controls the tendency of the kernel to reclaim

the memory which is used for caching of directory and inode objects.

At the default value of vfs_cache_pressure=100 the kernel will attempt to

reclaim dentries and inodes at a "fair" rate with respect to pagecache and

swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer

to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will

never reclaim dentries and inodes due to memory pressure and this can easily

lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100

causes the kernel to prefer to reclaim dentries and inodes.

Increasing vfs_cache_pressure significantly beyond 100 may have negative

performance impact. Reclaim code needs to take various locks to find freeable

directory and inode objects. With vfs_cache_pressure=1000, it will look for

ten times more freeable objects than there are.

If you don't need every single megabyte of freeable memory, taking it down to something low like 20 might save the phone a little bit of work destroying and then recreating the cache every time a low-memory situation occurs, but still allow freeing it up if things become truly dire. The typical memory usage when I poke /proc/meminfo is 10-18mb (marked as SReclaimable).

highmem_is_dirtyable: also not exposed by Kernel Adiutor. Default is 0 for our configuration, probably for good reason.

This defaults to 0 (false), meaning that the dirty_ratio and dirty_background_ratio ratios are calculated as a percentage of low memory only. This protects against excessive scanning in page reclaim, swapping and general VM distress.

Setting this to 1 can be useful on 32 bit machines where you want to make random changes within an memory mapped file that is larger than your available low memory without causing large quantities of random IO. It is safe if the behavior of all programs running on the machine is known and memory will not be otherwise stressed.

http://lime-technology.com/forum/index.php?topic=25431.0

"I believe this setting allows high ram to be used more for buffer cache."

I think we're under too much memory pressure for this to be beneficial; toggling it increased the number of slowdowns.

Don't touch overcommit_memory or overcommit_ratio, unless you want a mild headache and nothing to show for it. The former especially, if you set it to 2 (disabling overcommits entirely) instantly crashes everything - and I do mean

everything

- and it all refuses to come back up because they - various system services - are no longer allowed to request the 4x more memory than they will ever actually need. Linux memory management is weird.

For fun - not because it's really relevant to anything, as messing with it only causes tears - go cat /proc/meminfo or check it via Kernel Aduitor, and see what ridiculous heights your overcommit_AS reaches. Mine hovers between 7.5gb-1.2tb; far more than even a 4gb phone could reasonably serve if things were to somehow hit the fan.

(overcommit_AS is the worst-case "if every process loaded suddenly wants to use the potential maximum amount of memory they've been granted, this is how screwed you are" indicator; thankfully it's unlikely that such a thing would ever happen, as there're plenty of things in place to prevent it)

On a final note, my 3D performance has gone from "once in a blue moon runs as well as it should" to "nearly always runs as well as it should". While I certainly don't mind my stuff not being a laggy, shuttery mess - in particular Alphabear is actually pleasant to play again - I sure do wish I could figure out what I did to prompt its change of heart : \