PD#SWPL-16990
Problem:
Lost RAM will be over 200MB when playing 4K.
Solution:
Add cma pages in /proc/meminfo and give a information
for android layer to count them.
Verify:
x301
Change-Id: I99d1ded53ed351a5cb0d24f0e03850a55ef0d272
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
PD#SWPL-27030
Problem:
system would panic after enabling kmemleak.
Solution:
make sure the kernel thread stack addr is mapped to physical
memory before kmemleak scanning it.
Verify:
verified by sm1_s905x3_ac214.
Change-Id: I930e9c3d6e5930d4f71b42c2cdbc39d11c24eeb0
Signed-off-by: changqing.gao <changqing.gao@amlogic.com>
PD#SWPL-12145
Problem:
When switch IRQ stack, there is a 16 bytes miss match of irq
stack. This may cause context not match some times;
Solution:
Save sp to right place
Verify:
X301
Change-Id: I75dfa5208cb3cec050c1568ac78ae2e783ca106b
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
PD#SWPL-6837
Problem:
The return value of arch_counter_get_cntvct is always abnormal
when it is in irq stack. In this case, arch_counter_get_cntvct
trys to access a variable in 8Bytes via a 4Bytes aligned addr-
ess, which vialates the rule: The address that is accessed
should be aligned to the size of the data element being
accessed
Solution:
after switching to irq stack, force the base sp value to be
16Bytes aligned. Since the address of variable in irq stack is
based on the base sp and arranged automatically, all the data
accessing in irq stack will be aligned.
Verify:
Ampere
Change-Id: I3b30a56491dd0720d1c885bfaf2ca98d1b103fdd
Signed-off-by: Jiamin Ma <jiamin.ma@amlogic.com>
(cherry picked from commit 043ae971bf)
PD#SWPL-8132
Problem:
In Jira TV-5143, final fix change have increased 128MB address space
for vmalloc. Because binder wasted too many vmalloc space but it's
hard to fix it in kernel side.
Due to incease of vmalloc address space, old design of address space
layout for KASAN32 is not suitable after this change. So we need to
change memory layout to fix this problem and let KASAN can running OK
again.
Solution:
1, rebuild address space layout for kasan
2, make kasan compatible with vmap stack config
Verify:
p212
Change-Id: I2ce8a840df0ce1fcda61ebeb14a64b1d609719ca
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
PD#SWPL-4718
Problem:
Will have "PC=0, LR=0" issue when try to
show active cpu stacks via sysrq
Solution:
Save the addr of current interrupted task's context to the
interrupt stack first, so that we can easily obtain pt_regs
later
Verify:
Locally on Ampere
Change-Id: I1cc5095e0ec356bed90f76cdf9af1b2617ce7834
Signed-off-by: Jiamin Ma <jiamin.ma@amlogic.com>
PD#SWPL-2681
Problem:
If cpu support idle/hotplug, there are many vmap stack prints:
[ 74.096973@1] cpu 1, vmap stack:[e8e90000-e8e91de0]
[ 74.097084@1] cpu 1, irq stack:[e8e92000-e8e93de0]
[ 74.105901@3] cpu 3, vmap stack:[e8ee0000-e8ee1de0]
[ 74.105984@3] cpu 3, irq stack:[e8ee2000-e8ee3de0]
Solution:
Close these debug print
Verify:
P212
Change-Id: I000df1f0952328af9f359f20341eb0fe88590056
Signed-off-by: Tao Zeng <tao.zeng@amlogic.com>
PD#SWPL-2681
Problem:
Kernel stack usage is large when running many tasks.
Solution:
Map kernel stack to module space and handle page-fault
for stack fault. This can save about 50% memory of stack
usage
Verify:
p212
Change-Id: Ie894bc8f00cb525ddf8ac63c6d99d9c6e937fdc0
Signed-off-by: tao zeng <tao.zeng@amlogic.com>
PD#SWPL-1773
Problem:
After adding optimization of vmap stack, we can found stack usage
of each functions when handle vmap fault. From test log we see some
functions using large stack size which over 256bytes. Especially
common call path from fs. We need to optimize stack usage of these
functions to reduce stack fault probability and save stack memory
usage.
Solution:
1. remove CONFIG_CC_STACKPROTECTOR_STRONG and set STACKPROTECTOR to
NONE. This can save stack usage add by compiler for most functions.
Kernel code size can also save over 1MB.
2. Add some noinline functions for android_fs_data rw trace calls. In
these trace call it allcated a 256 bytes local buffer.
3. Add a wrap function for mem abort handler. By default, it defined a
siginfo struct(size over 100 bytes) in local but only used when fault
can't be handled.
4. reduce cached page size for vmap stack since probability of page
fault caused by stack overflow is reduced after function stack usage
optimized.
Monkey test show real stack usage ratio compared with 1st vmap
implementation reduced from 35% ~ 38% to 26 ~ 27%. Which is very
close to 25%, theory limit.
Verify:
P212
Change-Id: I5505cacc1cab51f88654052902852fd648b6a036
Signed-off-by: tao zeng <tao.zeng@amlogic.com>
PD#SWPL-1219
Problem:
On arm64, thread stack is 16KB for each task. If running task number
is large, this type of memory may over 40MB. It's a large amount on
small memory platform. But most case thread only use less 4KB stack.
It's waste of memory and we need optimize it.
Solution:
1. Pre-allocate a vmalloc address space for task stack;
2. Only map 1st page for stack and handle page fault in EL1
when stack growth triggered exception;
3. handle stack switch for exception.
Verify:
p212
Change-Id: I47f511ccfa2868d982bc10a820ed6435b6d52ba9
Signed-off-by: tao zeng <tao.zeng@amlogic.com>
