Skip to content
  • Joonsoo Kim's avatar
    mm/page_owner: use stackdepot to store stacktrace · f2ca0b55
    Joonsoo Kim authored
    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)
    (before the patch -> after the patch)
    
    static allocation:
    92274688 bytes -> 25165824 bytes
    
    dynamic allocation after boot + kernel build:
    0 bytes -> 327680 bytes
    
    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.
    
    [iamjoonsoo.kim@lge.com: mm-page_owner-use-stackdepot-to-store-stacktrace-v3]
      Link: http://lkml.kernel.org/r/1464230275-25791-6-git-send-email-iamjoonsoo.kim@lge.com
      Link: http://lkml.kernel.org/r/1466150259-27727-7-git-send-email-iamjoonsoo.kim@lge.com
    Link: http://lkml.kernel.org/r/1464230275-25791-6-git-send-email-iamjoonsoo.kim@lge.com
    
    
    Signed-off-by: default avatarJoonsoo Kim <iamjoonsoo.kim@lge.com>
    Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
    Acked-by: default avatarMichal Hocko <mhocko@suse.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    f2ca0b55