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>
Refactor the fs readpage/write tracepoints to move the
inode->path lookup outside the tracepoint code, and pass a pointer
to the path into the tracepoint code instead. This is necessary
because the tracepoint code runs non-preemptible. Thanks to
Trilok Soni for catching this in 4.4.
Signed-off-by: Mohan Srinivasan <srmohan@google.com>
Adds tracepoints in ext4/f2fs/mpage to track readpages/buffered
write()s. This allows us to track files that are being read/written
to PIDs. (Merged from android4.4-common).
Signed-off-by: Mohan Srinivasan <srmohan@google.com>
