[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+fCnZdRkJTG0Z1t00YGuzH4AFAicGUVyxFc63djewRz0vj=pQ@mail.gmail.com>
Date: Mon, 4 Sep 2023 20:45:09 +0200
From: Andrey Konovalov <andreyknvl@...il.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: andrey.konovalov@...ux.dev, Marco Elver <elver@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com,
Evgenii Stepanov <eugenis@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Andrey Konovalov <andreyknvl@...gle.com>
Subject: Re: [PATCH 00/15] stackdepot: allow evicting stack traces
On Wed, Aug 30, 2023 at 9:46 AM Vlastimil Babka <vbabka@...e.cz> wrote:
>
> I wonder if there's also another thing to consider for the future:
>
> 3. With the number of stackdepot users increasing, each having their
> distinct set of stacks from others, would it make sense to create separate
> "storage instance" for each user instead of putting everything in a single
> shared one?
This shouldn't be hard to implement. However, do you see any
particular use cases for this?
One thing that comes to mind is that the users will then be able to
create/destroy stack depot instances when required. But I don't know
if any of the users need this: so far they all seem to require stack
depot throughout the whole lifetime of the system.
> In any case, evicting support is a good development, thanks!
Thank you!
Powered by blists - more mailing lists