staging: android: lowmemorykiller: implement task's adj rbtree

Based on the current LMK implementation, LMK has to scan all processes to
select the correct task to kill during low memory.
The basic idea for the optimization is to :
queue all tasks with oom_score_adj priority, and then LMK just selects the
proper task from the queue(rbtree) to kill.

performance improvement:
the current implementation: average time to find a task to kill : 1004us
the optimized implementation: average time to find a task to kill: 43us

squished another 3 commits:

staging: android: lowmemorykiller: select a new task to kill
Under certain circumstances, a process may take time to handle a SIGKILL.
When lowmemkiller is called again shortly after, it would pick the same
process to kill over and over, so that we cann't get free memory for long time.

Solution is to check fatal_signal_pending() on the selected task, and if it's
already pending, select a new task to kill.

staging: android: lmk: skip if killed by lmk
A task can be selected to kill when it's already exiting. Sending
signal to the task at that state won't set TIF_SIGPENDING for it.
After that, every task including threads in the exiting task itself
running into lmk will compete for the mutex, then spend some time
waiting for the exiting task to release memory or try to send signal
to the same task again.
We want the exiting task to exit as early as possible but it's slowed
down greatly by the mutex and waiting. Skip lmk if current thread
group leader is exiting and is killed by lmk. Also delegate TIF_MEMDIE
to current task.

staging: android: lmk: check TIF directly
When trying to fix that lmk can't kill an exiting task
(commit 895304e
(CR) staging: android: lmk: skip if killed by lmk),
additional check was added for the TIF_MEMDIE flag.
However the task lock has already been taken when examining
the task. The same helper function which tries to grab the
task lock again will be deadlocked.
Change to check the thread flag of thread group leader directly.

Change-Id: Ibbb99cbd36e27a546195b4d4bed59b3829e6b7b0
binfmt_elf.c: use get_random_int() to fix entropy depleting.

Usually the entropy pool depletes very fast and stays in the 100-200 range.
After this patch, the entropy stays in the 600-1000 range without the risk of
depleting in normal workloads.

Change-Id: Ice0d0f14691046249d7b4a4d31af98ab80c6306b
makefile: enable -O3 optimizations
mm: skip already freed memory
block: add Sioplus scheduler
input: remove Sweep
tass: add cm7 ramdisk
cpufreq: SmartassV2 as default
tass: ramdisk fixes