From: Oscar Salvador <osalvador@suse.de>
To: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Michal Hocko <mhocko@suse.com>, Vlastimil Babka <vbabka@suse.cz>,
Eric Dumazet <edumazet@google.com>,
Waiman Long <longman@redhat.com>,
Suren Baghdasaryan <surenb@google.com>,
Marco Elver <elver@google.com>,
Alexander Potapenko <glider@google.com>
Subject: Re: [PATCH v2 1/3] lib/stackdepot: Add a refcount field in stack_record
Date: Tue, 6 Sep 2022 05:54:51 +0200 [thread overview]
Message-ID: <YxbEi7A3e+y5qNwY@localhost.localdomain> (raw)
In-Reply-To: <CA+fCnZcNr2JeCkTF=uCxjPCJKFi_d1chv0tjubvMisUdQtCeRw@mail.gmail.com>
On Mon, Sep 05, 2022 at 10:57:20PM +0200, Andrey Konovalov wrote:
> On Mon, Sep 5, 2022 at 5:10 AM Oscar Salvador <osalvador@suse.de> wrote:
> > +enum stack_depot_action {
> > + STACK_DEPOT_ACTION_NONE,
> > + STACK_DEPOT_ACTION_COUNT,
> > +};
>
> Hi Oscar,
Hi Andrey
> Why do we need these actions? Why not just increment the refcount on
> each stack trace save?
Let me try to explain it.
Back in RFC, there were no actions and the refcount
was incremented/decremented in __set_page_ownwer()
and __reset_page_owner() functions.
This lead to a performance "problem", where you would
look for the stack twice, one when save it
and one when increment it.
We figured we could do better and, at least, for the __set_page_owner()
we could look just once for the stacktrace when calling __stack_depot_save,
and increment it directly there.
We cannot do that for __reset_page_owner(), because the stack we are
saving is the freeing stacktrace, and we are not interested in that.
That is why __reset_page_owner() does:
<---
depot_stack_handle_t alloc_handle;
...
alloc_handle = page_owner->handle;
handle = save_stack(GFP_NOWAIT | __GFP_NOWARN, STACK_DEPOT_ACTION_NONE);
page_owner->free_handle = handle
stack_depot_dec_count(alloc_handle);
--->
alloc_handle contains the handle for the allocation stacktrace, which was set
in __set_page_owner(), and page_owner->free handle contains the handle for the
freeing stacktrace.
But we are only interested in the allocation stack and we only want to increment/decrement
that on allocation/free.
> Could you split out the stack depot and the page_owner changes into
> separate patches?
I could, I am not sure if it would make the review any easier though,
as you could not match stackdepot <-> page_owner changes.
And we should be adding a bunch of code that would not be used till later on.
But I can try it out if there is a strong opinion.
thanks for your time!
--
Oscar Salvador
SUSE Labs
next prev parent reply other threads:[~2022-09-06 3:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-05 3:10 [PATCH v2 0/3] page_owner: print stacks and their counter Oscar Salvador
2022-09-05 3:10 ` [PATCH v2 1/3] lib/stackdepot: Add a refcount field in stack_record Oscar Salvador
2022-09-05 20:57 ` Andrey Konovalov
2022-09-06 3:54 ` Oscar Salvador [this message]
2022-09-10 22:33 ` Andrey Konovalov
2022-09-19 15:01 ` Vlastimil Babka
2022-09-05 3:10 ` [PATCH v2 2/3] mm, page_owner: Add page_owner_stacks file to print out only stacks and their counter Oscar Salvador
2022-09-05 12:57 ` Marco Elver
2022-09-05 13:00 ` Marco Elver
2022-09-06 7:43 ` Oscar Salvador
2022-09-06 8:35 ` Marco Elver
2022-09-07 4:00 ` Oscar Salvador
2022-09-07 7:14 ` Marco Elver
2022-09-08 3:32 ` Oscar Salvador
2022-09-08 5:31 ` Marco Elver
2022-09-05 22:20 ` kernel test robot
2022-09-05 3:10 ` [PATCH v2 3/3] mm,page_owner: Filter out stacks by a threshold counter Oscar Salvador
2022-09-05 10:51 ` Ammar Faizi
2022-09-05 11:31 ` Michal Hocko
2022-09-05 11:54 ` Ammar Faizi
2022-09-05 12:02 ` Michal Hocko
2022-09-05 12:42 ` Ammar Faizi
2022-09-19 15:23 ` Vlastimil Babka
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=YxbEi7A3e+y5qNwY@localhost.localdomain \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=edumazet@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mhocko@suse.com \
--cc=surenb@google.com \
--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;
as well as URLs for NNTP newsgroup(s).