On Mon, Jun 06, 2016 at 03:56:04PM +0200, Michal Hocko wrote: > 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? No, first number refers to the static allocation before the patch and second one is for after the patch. > > > dynamic allocation after kernel build: > > 0 bytes -> 327680 bytes > > And this is the additional dynamic allocation after the kernel build. This is the additional dynamic allocation after booting + the kernel build. (before the patch -> after the patch) > > 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> Thanks. > > --- > > 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) Will add. Thanks. -- 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>