[LeEco Le Pro3 ROMs, Kernels, Recoveries, & Other D] mosimchah:
More info on kernel settings:

Low Memory Killer

source- http://androidcentral.com/fine-tuning-minfree-settings-improving-androids-multi-tasking

FOREGROUND_APP: This is the application currently on the screen, and running

VISIBLE_APP: This is an application that is open, and running in the background because it's still doing something

SECONDARY_SERVER: This is a process (a service that an application needs) that is alive and ready in case it's needed to do something

HIDDEN_APP: This again is a process, that sits idle (but still alive) in case it's needed by an app that's alive and running

For the most part, we never want to adjust when these apps and processes are killed off. They are the things that the programs we use need to properly function. For the more bold and advanced users, changing settings for HIDDEN_APP settings is possible, albeit with a LOT of trial and error. There's two more settings, and these are the ones most interesting to us today:

CONTENT_PROVIDER: This is apps that provide data (content) to the system. Facebook Sync? That's a CONTENT_PROVIDER. So are things like the Google play store. If they are alive, they can refresh and provide the content they are supposed to at the set interval. If you kill them, they can't of course.

EMPTY_APP:They are apps that you have opened, but are done with them. Android uses a unique style of handling memory management. When an activity is ended, instead of killing it off Android keeps the application in memory so that opening them again is a faster process. Theses "ghost" apps use no battery or CPU time, they just fill RAM that would be otherwise empty. When this memory is needed by a different application or process, the RAM is flushed and made available for the new app. Android does this by keeping a list of recently used apps, with the oldest apps in the list given the lowest priority -- they are killed first if RAM is needed elsewhere. This is a perfect way to handle 'ghost' processes

Virtual Memory

this is the really fun stuff ;)

source- the Linux kernel documentation https://github.com/AICP/kernel_leeco_msm8996/blob/n7.1/Documentation/sysctl/vm.txt

dirty_background_ratio:

Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which the background kernel flusher threads will start writing out dirty data.

The total available memory is not equal to total system memory.

dirty_ratio:

Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which a process which is generating disk writes will itself start writing out dirty data.

The total available memory is not equal to total system memory.

dirty_expire_centisecs:

This tunable is used to define when dirty data is old enough to be eligible for write out by the kernel flusher threads. It is expressed in 100'ths of a second. Data which has been dirty in-memory for longer than this interval will be written out next time a flusher thread wakes up.

dirty_writeback_centisecs:

The kernel flusher threads will periodically wake up and write `old' data out to disk. This tunable expresses the interval between those wakeups, in 100'ths of a second.

Setting this to zero disables periodic write back altogether.

extra_free_kbytes:

This parameter tells the VM to keep extra free memory between the threshold where background reclaim (kswapd) kicks in, and the threshold where direct reclaim (by allocating processes) kicks in.

This is useful for workloads that require low latency memory allocations and have a bounded burstiness in memory allocations, for example, a realtime application that receives and transmits network traffic (causing in-kernel memory allocations) with a maximum total message burst size of 200MB may need 200MB of extra free memory to avoid direct reclaim related latencies.

min_free_kbytes:

This is used to force the Linux VM to keep a minimum number of kilobytes free. The VM uses this number to compute a watermark[WMARK_MIN] value for each lowmem zone in the system.

Each lowmem zone gets a number of reserved free pages based proportionally on its size.

Some minimal amount of memory is needed to satisfy PF_MEMALLOC allocations; if you set this to lower than 1024KB, your system will become subtly broken, and prone to deadlock under high loads.

Setting this too high will OOM your machine instantly.

oom_kill_allocating_task:

This enables or disables killing the OOM-triggering task in out-of-memory situations.

If this is set to zero, the OOM killer will scan through the entire tasklist and select a task based on heuristics to kill. This normally selects a rogue memory-hogging task that frees up a large amount of memory when killed.

If this is set to non-zero, the OOM killer simply kills the task that triggered the out-of-memory condition. This avoids the expensive tasklist scan.

If panic_on_oom is selected, it takes precedence over whatever value is used in oom_kill_allocating_task.

The default value is 0.

swappiness:

This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase aggressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone.

zRam

source- https://sites.google.com/site/easylinuxtipsproject/speed#TOC-Only-768-MB-RAM-or-less:-enable-zRam

zRam creates a compressed swap file in your RAM. The compression factor is the gain: with that, you "increase" your RAM.

The price you pay for this, is:

- Your processor (CPU) is being taxed more heavily, because it'll have to compress and decompress all the time;.

That's why, I advise zRam only for phones with very little RAM (Not zl1), and even then only in combination with a swappiness that has been decreased to 5.

Misc

Vibration strength:

Obviously this controls the strength of the vibrations, setting this to a lower value will increase battery life, setting it to zero will disable all vibrations (Kind of, you'll still get a very subtle vibration, but chances are you won't even notice it)

TCP CONGESTION ALGORITHMS:

source- http://androidmodguide.blogspot.com/p/tcp-algorithms.html?m=1

Tahoe:

Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.

Reno:

Basically the same as Tahoe, but if 3 of the same packets are received, it will halve the window, instead of reducing it to one. It changes the slow start threshold equal to that of the congestion window.

Cubic:

One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.

Vegas:

One of the smoothest TCP algorithms(next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.

Veno:

Veno is closely related to Vegas, it is a combination of Vegas and Reno in order to enhance TCP performance over Wireless networks.

Low Priority (LP):

A distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the "fair share" of bandwidth as targeted by TCP. The key mechanisms unique to TCP-LP congestion control are the use of one-way packet delays for early congestion indications and a TCP-transparent congestion avoidance policy.

Binary Increase Congestion control (BIC):

BIC is optimized for high speed networks with high latency: so-called "long fat networks". It has a unique congestion window (cwnd) algorithm. This algorithm tries to find the maximum where to keep the window at for a long period of time, by using a binary search algorithm.

Scalable:

Scalable calls for congestion window to be halved for each packet lost. Effectively, this process keeps halving the throughput until packet loss stops. Once the packet loss subsides, slow start kicks in to ramp the speed back up.

Hamilton TCP (HTCP):

HTCP is designed for high-speed, long distance networks that increases aggressiveness as the time since the previous loss increases. It is thought to be a more efficient TCP algorithm than BIC and HSTCP.

Illinois:

Illinois is designed for high-speed, long-distance networks. A sender side modification to the standard TCP congestion control algorithm, it achieves a higher average throughput than the standard TCP and allocates the network resource fairly as the standard TCP.

High speed (HSTCP):

High Speed TCP (HSTCP) is a new congestion control algorithm protocol for TCP. Standard TCP performs poorly in networks with a large bandwidth delay product. It is unable to fully utilize available bandwidth. HSTCP makes minor modifications to standard TCP's congestion control mechanism to overcome this limitation.

Yeah-TCP:

A high speed TCP congestion control algorithm which uses a mixed loss/delay approach to calculate congestion windows. Its purpose is to target high efficiency, fairness, and minimizing link loss while keeping network elements load as low as possible.

Westwood:

A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date.

I recommend using Westwood for everything, and only use cubic if all you care about is stability and don't mind losses in performance, and latency, and stuff like that