linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Potapenko <glider@google.com>
To: Vijayanand Jitta <vjitta@codeaurora.org>
Cc: Minchan Kim <minchan@kernel.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	dan.j.williams@intel.com, broonie@kernel.org,
	Masami Hiramatsu <mhiramat@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrey Konovalov <andreyknvl@google.com>,
	qcai@redhat.com, ylal@codeaurora.org, vinmenon@codeaurora.org,
	kasan-dev <kasan-dev@googlegroups.com>
Subject: Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE
Date: Thu, 17 Dec 2020 11:54:36 +0100	[thread overview]
Message-ID: <CAG_fn=UXQUGiDqmChqD-xX-yF5Jp+7K+oHwKPrO9DZL-zW_4KQ@mail.gmail.com> (raw)
In-Reply-To: <9e0d2c07-af1f-a1d3-fb0d-dbf2ae669f96@codeaurora.org>

> > Can you provide an example of a use case in which the user wants to
> > use the stack depot of a smaller size without disabling it completely,
> > and that size cannot be configured statically?
> > As far as I understand, for the page owner example you gave it's
> > sufficient to provide a switch that can disable the stack depot if
> > page_owner=off.
> >
> There are two use cases here,
>
> 1. We don't want to consume memory when page_owner=off ,boolean flag
> would work here.
>
> 2. We would want to enable page_owner on low ram devices but we don't
> want stack depot to consume 8 MB of memory, so for this case we would
> need a configurable stack_hash_size so that we can still use page_owner
> with lower memory consumption.
>
> So, a configurable stack_hash_size would work for both these use cases,
> we can set it to '0' for first case and set the required size for the
> second case.

Will a combined solution with a boolean boot-time flag and a static
CONFIG_STACKDEPOT_HASH_SIZE work for these cases?
I suppose low-memory devices have a separate kernel config anyway?

My concern is that exposing yet another knob to users won't really
solve their problems, because the hash size alone doesn't give enough
control over stackdepot memory footprint (we also have stack_slabs,
which may get way bigger than 8Mb).

  parent reply	other threads:[~2020-12-17 10:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10  5:00 [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE vjitta
2020-12-11  8:36 ` Alexander Potapenko
2020-12-11 12:45   ` Vijayanand Jitta
2020-12-11 13:25     ` Alexander Potapenko
2020-12-14  4:02       ` Vijayanand Jitta
2020-12-14  9:34         ` Alexander Potapenko
2020-12-14 10:32           ` Vijayanand Jitta
2020-12-16  3:43             ` Vijayanand Jitta
2020-12-16  8:26               ` Alexander Potapenko
2020-12-16 13:06                 ` Vijayanand Jitta
2020-12-16 13:11                   ` Alexander Potapenko
2020-12-16 13:22                     ` Vijayanand Jitta
2020-12-16 13:34                       ` Alexander Potapenko
2020-12-17  5:38                         ` Vijayanand Jitta
2020-12-17 10:19                           ` Dmitry Vyukov
2020-12-17 10:54                           ` Alexander Potapenko [this message]
2020-12-18  8:40                             ` Vijayanand Jitta
2020-12-21 11:14                               ` Vijayanand Jitta
2020-12-21 15:04                                 ` Alexander Potapenko
2020-12-21 20:29                                   ` Minchan Kim
2020-12-22  5:55                                     ` Vijayanand Jitta
2020-12-23 14:40                                       ` Alexander Potapenko
2020-12-28  4:51                                         ` Vijayanand Jitta
2020-12-15  9:34 ` [lib] 1333d0ba67: WARNING:at_kernel/locking/lockdep.c:#lockdep_register_key kernel test robot
2020-12-17 10:25 ` [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE Dmitry Vyukov
2020-12-17 10:27   ` Dmitry Vyukov

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='CAG_fn=UXQUGiDqmChqD-xX-yF5Jp+7K+oHwKPrO9DZL-zW_4KQ@mail.gmail.com' \
    --to=glider@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=broonie@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=minchan@kernel.org \
    --cc=qcai@redhat.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=vinmenon@codeaurora.org \
    --cc=vjitta@codeaurora.org \
    --cc=ylal@codeaurora.org \
    /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).