linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	mgorman@techsingularity.net, Minchan Kim <minchan@kernel.org>,
	Alexander Potapenko <glider@google.com>,
	Hugh Dickins <hughd@google.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v2 6/7] mm/page_owner: use stackdepot to store stacktrace
Date: Mon, 20 Jun 2016 15:58:41 +0900	[thread overview]
Message-ID: <20160620065841.GC13747@js1304-P5Q-DELUXE> (raw)
In-Reply-To: <20160617095559.GC21670@dhcp22.suse.cz>

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>

--
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>

  reply	other threads:[~2016-06-20  6:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-26  2:37 [PATCH v2 1/7] mm/compaction: split freepages without holding the zone lock js1304
2016-05-26  2:37 ` [PATCH v2 2/7] mm/page_owner: initialize page owner " js1304
2016-06-03 10:23   ` Vlastimil Babka
2016-06-03 12:47     ` Joonsoo Kim
2016-06-06 15:20       ` Vlastimil Babka
2016-05-26  2:37 ` [PATCH v2 3/7] mm/page_owner: copy last_migrate_reason in copy_page_owner() js1304
2016-06-06 13:31   ` Vlastimil Babka
2016-05-26  2:37 ` [PATCH v2 4/7] mm/page_owner: introduce split_page_owner and replace manual handling js1304
2016-05-26  2:37 ` [PATCH v2 5/7] tools/vm/page_owner: increase temporary buffer size js1304
2016-05-26  2:37 ` [PATCH v2 6/7] mm/page_owner: use stackdepot to store stacktrace js1304
2016-06-06 13:56   ` Michal Hocko
2016-06-17  7:25     ` Joonsoo Kim
2016-06-17  9:55       ` Michal Hocko
2016-06-20  6:58         ` Joonsoo Kim [this message]
2016-06-06 14:51   ` Vlastimil Babka
2016-06-20 13:04     ` Alexander Potapenko
2016-05-26  2:37 ` [PATCH v2 7/7] mm/page_alloc: introduce post allocation processing on page allocator js1304
2016-06-06 15:21   ` Vlastimil Babka
2016-06-17  7:55     ` Joonsoo Kim
2016-06-03 10:10 ` [PATCH v2 1/7] mm/compaction: split freepages without holding the zone lock Vlastimil Babka
2016-06-03 12:45   ` Joonsoo Kim
2016-06-06 15:19     ` Vlastimil Babka
2016-06-13 20:31 ` Sasha Levin
2016-06-14  5:52   ` Joonsoo Kim
2016-06-14 19:10     ` Sasha Levin
2016-06-15  2:27       ` Joonsoo Kim
2016-06-17  7:27         ` Joonsoo Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160620065841.GC13747@js1304-P5Q-DELUXE \
    --to=iamjoonsoo.kim@lge.com \
    --cc=akpm@linux-foundation.org \
    --cc=glider@google.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox