Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <1607576401-25609-1-git-send-email-vjitta@codeaurora.org>
 <CAG_fn=VKsrYx+YOGPnZw_Q5t6Fx7B59FSUuphj7Ou+DDFKQ+8Q@mail.gmail.com>
 <77e98f0b-c9c3-9380-9a57-ff1cd4022502@codeaurora.org> <CAG_fn=WbN6unD3ASkLUcEmZvALOj=dvC0yp6CcJFkV+3mmhwxw@mail.gmail.com>
 <6cc89f7b-bf40-2fd3-96ce-2a02d7535c91@codeaurora.org> <CAG_fn=VOHag5AUwFbOj_cV+7RDAk8UnjjqEtv2xmkSDb_iTYcQ@mail.gmail.com>
 <255400db-67d5-7f42-8dcb-9a440e006b9d@codeaurora.org> <f901afa5-7c46-ceba-2ae9-6186afdd99c0@codeaurora.org>
 <CAG_fn=UjJQP_gfDm3eJTPY371QTwyDJKXBCN2gs4DvnLP2pbyQ@mail.gmail.com>
 <7f2e171f-fa44-ef96-6cc6-14e615e3e457@codeaurora.org> <CAG_fn=VihkHLx7nHRrzQRuHeL-UYRezcyGLDQMJY+d1O5AkJfA@mail.gmail.com>
 <601d4b1a-8526-f7ad-d0f3-305894682109@codeaurora.org> <CAG_fn=V8e8y1fbOaYUD5SfDSQ9+Tc3r7w6ZSoJ-ZNFJvvq-Aeg@mail.gmail.com>
 <9e0d2c07-af1f-a1d3-fb0d-dbf2ae669f96@codeaurora.org>
In-Reply-To: <9e0d2c07-af1f-a1d3-fb0d-dbf2ae669f96@codeaurora.org>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Thu, 17 Dec 2020 11:19:24 +0100
Message-ID: <CACT4Y+aUEdNjFsnMxFAbh+cWMGLG1bqX8-7uo8SQ0HPeNeDZBg@mail.gmail.com>
Subject: Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE
To:     Vijayanand Jitta <vjitta@codeaurora.org>,
        kasan-dev <kasan-dev@googlegroups.com>
Cc:     Alexander Potapenko <glider@google.com>,
        Minchan Kim <minchan@kernel.org>,
        Vincenzo Frascino <vincenzo.frascino@arm.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Mark Brown <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
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Dec 17, 2020 at 6:42 AM Vijayanand Jitta <vjitta@codeaurora.org> wrote:
>
> On 12/16/2020 7:04 PM, Alexander Potapenko wrote:
> >>> To reiterate, I think you don't need a tunable stack_hash_order
> >>> parameter if the only use case is to disable the stack depot.
> >>> Maybe it is enough to just add a boolean flag?
> >>
> >> There are multiple users of stackdepot they might still want to use
> >> stack depot but with a lower memory footprint instead of MAX_SIZE
> >> so, a configurable size might help here ?
> >
> > 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.
>
> >>> Or even go further and disable the stack depot in the same place that
> >>> disables page owner, as the user probably doesn't want to set two
> >>> flags instead of one?
> >>>
> >>
> >> Since, page owner is not the only user of stack depot we can't take that
> >> decision of disabling stack depot if page owner is disabled.
> >
> > Agreed, but if multiple subsystems want to use stackdepot together, it
> > is even harder to estimate the total memory consumption.
> > How likely is it that none of them will need MAX_SIZE?
> >
> >>>> Minchan,
> >>>> This should be fine right ? Do you see any issue with disabling
> >>>> stack depot completely ?

+kasan-dev