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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160620065841.GC13747@js1304-P5Q-DELUXE>
Date:	Mon, 20 Jun 2016 15:58:41 +0900
From:	Joonsoo Kim <iamjoonsoo.kim@....com>
To:	Michal Hocko <mhocko@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Vlastimil Babka <vbabka@...e.cz>, mgorman@...hsingularity.net,
	Minchan Kim <minchan@...nel.org>,
	Alexander Potapenko <glider@...gle.com>,
	Hugh Dickins <hughd@...gle.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH v2 6/7] mm/page_owner: use stackdepot to store stacktrace

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@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>