Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1424744 > unrolled thread

Re: [PATCH v2 6/7] mm/page_owner: use stackdepot to store stacktrace

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 6/7] mm/page_owner: use stackdepot to store stacktrace Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-06-17 09:30 +0200
    Re: [PATCH v2 6/7] mm/page_owner: use stackdepot to store stacktrace Michal Hocko <mhocko@kernel.org> - 2016-06-17 12:00 +0200
      Re: [PATCH v2 6/7] mm/page_owner: use stackdepot to store stacktrace Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-06-20 09:00 +0200

#1424744 — Re: [PATCH v2 6/7] mm/page_owner: use stackdepot to store stacktrace

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@lge.com>
> > 
> > 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@lge.com>
> 
> Other than the small remark below I haven't spotted anything wrong and
> I like the approach.
> 
> Acked-by: Michal Hocko <mhocko@suse.com>

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.

[toc] | [next] | [standalone]

#1424863

On Fri 17-06-16 16:25:26, Joonsoo Kim wrote:
> On Mon, Jun 06, 2016 at 03:56:04PM +0200, Michal Hocko wrote:
[...]
> > 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.

I guess we are both talking about the same thing in different words. All
the allocations are static before the patch while all are dynamic after
the patch. Your boot example just shows how much dynamic memory gets
allocated during your boot. This will depend on the particular
configuration but it will at least give a picture what the savings might
be.
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1426254

On Fri, Jun 17, 2016 at 11:55:59AM +0200, Michal Hocko wrote:
> On Fri 17-06-16 16:25:26, Joonsoo Kim wrote:
> > On Mon, Jun 06, 2016 at 03:56:04PM +0200, Michal Hocko wrote:
> [...]
> > > 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.
> 
> I guess we are both talking about the same thing in different words. All
> the allocations are static before the patch while all are dynamic after

Hmm... maybe no? After the patch, there is two parts, static and dynamic.
Page extension has following fields for page owner.

Before the patch
{
 unsigned int order;
 gfp_t gfp_mask;
 unsigned int nr_entries;
 int last_migrate_reason;
 unsigned long trace_entries[8];
}

After the patch
{
 unsigned int order;
 gfp_t gfp_mask;
 int last_migrate_reason;
 depot_stack_handle_t handle;
}

This structure should be allocated for each page even if the patch is
applied so I said it as static memory usage. There is an amount
difference since 'trace_entries[8]' field is changed to 'handle'
field.

Before the patch, stacktrace is stored to static allocated memory per
page. So, no dynamic usage.

After the patch, handle is returned by stackdepot and stackdepot
consumes some memory for it. I said it as dynamic.

Thanks.

> the patch. Your boot example just shows how much dynamic memory gets
> allocated during your boot. This will depend on the particular
> configuration but it will at least give a picture what the savings might
> be.
> -- 
> Michal Hocko
> SUSE Labs
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web