linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Oscar Salvador <osalvador@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,  linux-mm@kvack.org,
	Michal Hocko <mhocko@suse.com>, Vlastimil Babka <vbabka@suse.cz>,
	 Andrey Konovalov <andreyknvl@gmail.com>,
	Alexander Potapenko <glider@google.com>
Subject: Re: [PATCH v7 2/4] mm,page_owner: Implement the tracking of the stacks count
Date: Fri, 9 Feb 2024 22:42:42 +0100	[thread overview]
Message-ID: <CANpmjNPM4aKMWAmxWEMQ-Antq0jDFauOya2XHHX5RhnONucgrg@mail.gmail.com> (raw)
In-Reply-To: <ZcabeMCHCkl3Bf6q@localhost.localdomain>

On Fri, 9 Feb 2024 at 22:37, Oscar Salvador <osalvador@suse.de> wrote:
>
> On Fri, Feb 09, 2024 at 08:45:00AM +0100, Marco Elver wrote:
> > > +/**
> > > + * stack_depo_get_stack - Get a pointer to a stack struct
> >
> > Typo: "depo" -> depot
> >
> > I would also write "stack_record struct", because "stack struct" does not exist.
>
> Fixed.
>
> > > + * @handle: Stack depot handle
> > > + *
> > > + * Return: Returns a pointer to a stack struct
> > > + */
> > > +struct stack_record *stack_depot_get_stack(depot_stack_handle_t handle);
> >
> > I don't know what other usecases there are for this, but I'd want to
> > make make sure we give users a big hint to avoid unnecessary uses of
> > this function.
> >
> > Perhaps we also want to mark it as somewhat internal, e.g. by
> > prefixing it with __. So I'd call it __stack_depot_get_stack_record().
>
> Yes, I went with __stack_depot_get_stack_record(), and I updated its doc
> in stackdepot.h, mentioning that is only for internal purposes.
>
> > > +static void inc_stack_record_count(depot_stack_handle_t handle)
> > > +{
> > > +       struct stack_record *stack = stack_depot_get_stack(handle);
> > > +
> > > +       if (stack)
> > > +               refcount_inc(&stack->count);
> > > +}
> >
> > In the latest stackdepot version in -next, the count is initialized to
> > REFCOUNT_SATURATED to warn if a non-refcounted entry is suddenly used
> > as a refcounted one. In your case this is intentional and there is no
> > risk that the entry will be evicted, so that's ok. But you need to set
> > the refcount to 1 somewhere here on the initial stack_depot_save().
>
> Well, I went with something like:
>
>  static void inc_stack_record_count(depot_stack_handle_t handle)
>  {
>          struct stack_record *stack = __stack_depot_get_stack_record(handle);
>
>          if (stack) {
>                  /*
>                   * New stack_records that do not use STACK_DEPOT_FLAG_GET start
>                   * with REFCOUNT_SATURATED to catch spurious increments of their
>                   * refcount.
>                   * Since we do not use STACK_DEPOT_FLAG_{GET,PUT} API, let us

There is no FLAG_PUT, only stack_depot_put(). Saying you do not use
the refcount to free any entries should hopefully make it clear that
even if the refcount saturates and you wrap around to 1, nothing
catastrophic will happen.

>                   * set a refcount of 1 ourselves.
>                   */
>                  if (refcount_read(&stack->count) == REFCOUNT_SATURATED)
>                          refcount_set(&stack->count, 1);
>                  refcount_inc(&stack->count);
>          }
>  }

That looks reasonable.


  reply	other threads:[~2024-02-09 21:43 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-08 23:45 [PATCH v7 0/4] page_owner: print stacks and their outstanding allocations Oscar Salvador
2024-02-08 23:45 ` [PATCH v7 1/4] lib/stackdepot: Move stack_record struct definition into the header Oscar Salvador
2024-02-09  7:45   ` Marco Elver
2024-02-09 21:33     ` Oscar Salvador
2024-02-09 17:39   ` kernel test robot
2024-02-10  9:59   ` kernel test robot
2024-02-08 23:45 ` [PATCH v7 2/4] mm,page_owner: Implement the tracking of the stacks count Oscar Salvador
2024-02-09  7:37   ` Marco Elver
2024-02-09  7:45   ` Marco Elver
2024-02-09 21:39     ` Oscar Salvador
2024-02-09 21:42       ` Marco Elver [this message]
2024-02-09 21:44         ` Marco Elver
2024-02-11 20:42           ` Oscar Salvador
2024-02-08 23:45 ` [PATCH v7 3/4] mm,page_owner: Display all stacks and their count Oscar Salvador
2024-02-09  8:00   ` Marco Elver
2024-02-09 21:52     ` Oscar Salvador
2024-02-09 23:14       ` Oscar Salvador
2024-02-10  7:52         ` Marco Elver
2024-02-11 20:39           ` Oscar Salvador
2024-02-12 10:47             ` Vlastimil Babka
2024-02-09 23:14   ` kernel test robot
2024-02-08 23:45 ` [PATCH v7 4/4] mm,page_owner: Filter out stacks by a threshold Oscar Salvador
2024-02-09  0:28 ` [PATCH v7 0/4] page_owner: print stacks and their outstanding allocations Andrew Morton
2024-02-09 21:31   ` Oscar Salvador
2024-02-09  8:03 ` Marco Elver
2024-02-09 21:32   ` Oscar Salvador

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=CANpmjNPM4aKMWAmxWEMQ-Antq0jDFauOya2XHHX5RhnONucgrg@mail.gmail.com \
    --to=elver@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=glider@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --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