linux-kernel - Re: [PATCH 0/3] mm/page_owner: add options 'print_handle' and 'print_stack' for 'show

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <aNY49sdoFVe03m_Y@tiehlicka>
Date: Fri, 26 Sep 2025 08:55:50 +0200
From: Michal Hocko <mhocko@...e.com>
To: Mauricio Faria de Oliveira <mfo@...lia.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Vlastimil Babka <vbabka@...e.cz>,
	Oscar Salvador <osalvador@...e.de>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Brendan Jackman <jackmanb@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>, Zi Yan <ziy@...dia.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	kernel-dev@...lia.com
Subject: Re: [PATCH 0/3] mm/page_owner: add options 'print_handle' and
 'print_stack' for 'show_stacks'

On Thu 25-09-25 16:38:46, Mauricio Faria de Oliveira wrote:
> On 2025-09-25 13:08, Michal Hocko wrote:
[...]
> > Could you elaborate some more on why the performance really matters here?
> 
> Sure.
> 
> One reason is optimizing data processing.
> 
> Currently, the step to obtain the key of a strack trace (e.g., hashing)
> incurs
> a considerable work (done for all stack traces, on every sample) that
> actually
> is duplicated work (the same result for each stack trace, on every
> sample).

OK, that was not really clear to me but the above seems to suggest that
by hashing you really mean hashing in the userspace when trying to
create a key so that you can watch memory consumption trends per stack
trace (hash in this case) without post processing.

Stating that more explicitly in the changelog along with an example on
how you are using this would be really helpful. 

When the interface was originally introduced the primary usecase was to
examine biggest memory consumers - e.g. when memory counters do not add
up to counters that track most common users (e.g. userspace memory, slab
caches etc.). In those case you need to see those stack traces as those
are giving you the most valuable information.

I can see you are coming from a different direction and you want to
collect data repeatedly and watch for trends rather than analyzing a
particular situation. This seems like a useful usecase in itself.

My main question is whether this should squashed into the existing file
with a rather strange semantic of controling the file content depending
on a different file content. Instead, would it make more sense to add
two more files, one to display your requested key:value data and another
to resolve key -> stack trace?

-- 
Michal Hocko
SUSE Labs