On Thu 26-05-16 11:37:54, Joonsoo Kim wrote: > From: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> > > Currently, we store each page's allocation stacktrace on corresponding > page_ext structure and it requires a lot of memory. This causes the problem > that memory tight system doesn't work well if page_owner is enabled. > Moreover, even with this large memory consumption, we cannot get full > stacktrace because we allocate memory at boot time and just maintain > 8 stacktrace slots to balance memory consumption. We could increase it > to more but it would make system unusable or change system behaviour. > > To solve the problem, this patch uses stackdepot to store stacktrace. > It obviously provides memory saving but there is a drawback that > stackdepot could fail. > > stackdepot allocates memory at runtime so it could fail if system has > not enough memory. But, most of allocation stack are generated at very > early time and there are much memory at this time. So, failure would not > happen easily. And, one failure means that we miss just one page's > allocation stacktrace so it would not be a big problem. In this patch, > when memory allocation failure happens, we store special stracktrace > handle to the page that is failed to save stacktrace. With it, user > can guess memory usage properly even if failure happens. > > Memory saving looks as following. (4GB memory system with page_owner) I still have troubles to understand your numbers > static allocation: > 92274688 bytes -> 25165824 bytes I assume that the first numbers refers to the static allocation for the given amount of memory while the second one is the dynamic after the boot, right? > dynamic allocation after kernel build: > 0 bytes -> 327680 bytes And this is the additional dynamic allocation after the kernel build. > total: > 92274688 bytes -> 25493504 bytes > > 72% reduction in total. > > Note that implementation looks complex than someone would imagine because > there is recursion issue. stackdepot uses page allocator and page_owner > is called at page allocation. Using stackdepot in page_owner could re-call > page allcator and then page_owner. That is a recursion. To detect and > avoid it, whenever we obtain stacktrace, recursion is checked and > page_owner is set to dummy information if found. Dummy information means > that this page is allocated for page_owner feature itself > (such as stackdepot) and it's understandable behavior for user. > > v2: > o calculate memory saving with including dynamic allocation > after kernel build > o change maximum stacktrace entry size due to possible stack overflow > > Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> Other than the small remark below I haven't spotted anything wrong and I like the approach. Acked-by: Michal Hocko <mhocko@xxxxxxxx> > --- > include/linux/page_ext.h | 4 +- > lib/Kconfig.debug | 1 + > mm/page_owner.c | 138 ++++++++++++++++++++++++++++++++++++++++------- > 3 files changed, 122 insertions(+), 21 deletions(-) > [...] > @@ -7,11 +7,18 @@ > #include <linux/page_owner.h> > #include <linux/jump_label.h> > #include <linux/migrate.h> > +#include <linux/stackdepot.h> > + > #include "internal.h" > This is still 128B of the stack which is a lot in the allocation paths so can we add something like /* * TODO: teach PAGE_OWNER_STACK_DEPTH (__dump_page_owner and save_stack) * to use off stack temporal storage */ > +#define PAGE_OWNER_STACK_DEPTH (16) -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>