From: Vlastimil Babka <vbabka@suse.cz>
To: Roman Gushchin <guro@fb.com>
Cc: akpm@linux-foundation.org, bigeasy@linutronix.de, cl@linux.com,
hannes@cmpxchg.org, iamjoonsoo.kim@lge.com, jannh@google.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
mhocko@kernel.org, minchan@kernel.org, penberg@kernel.org,
rientjes@google.com, shakeelb@google.com, surenb@google.com,
tglx@linutronix.de
Subject: Re: [RFC 2/2] mm, slub: add shrinker to reclaim cached slabs
Date: Tue, 26 Jan 2021 13:06:35 +0100 [thread overview]
Message-ID: <51de513a-9c4e-35fa-fd04-977480ac50a0@suse.cz> (raw)
In-Reply-To: <20210122004847.GA25567@carbon.dhcp.thefacebook.com>
On 1/22/21 1:48 AM, Roman Gushchin wrote:
> On Thu, Jan 21, 2021 at 06:21:54PM +0100, Vlastimil Babka wrote:
>
> Hi Vlastimil!
>
> This makes a lot of sense, however it looks a bit as an overkill to me (on 5.9+).
> Isn't limiting a number of pages (instead of number of objects) sufficient on 5.9+?
It would help, but fundamentally there can still be a lot of memory locked up
with e.g. many CPU's. We should have a way to flush this automatically, like for
other cached things.
> If not, maybe we can limit the shrinking to the pre-OOM condition?
> Do we really need to trip it constantly?
The priority could be reduced, pre-OOM might be too extreme. Why reclaim e.g.
actually used LRU pages instead of unused slab pages?
IMHO a frequently reclaiming system probably doesn't benefit from SLUB's peak
performance at that point anyway...
> Thanks!
>
prev parent reply other threads:[~2021-01-26 12:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 23:12 SLUB: percpu partial object count is highly inaccurate, causing some memory wastage and maybe also worse tail latencies? Jann Horn
2021-01-11 23:12 ` Jann Horn
2021-01-12 0:27 ` Roman Gushchin
2021-01-12 16:35 ` Christoph Lameter
2021-01-12 16:35 ` Christoph Lameter
2021-01-14 9:27 ` Vlastimil Babka
2021-01-18 11:03 ` Michal Hocko
2021-01-18 15:46 ` Christoph Lameter
2021-01-18 15:46 ` Christoph Lameter
2021-01-18 16:07 ` Michal Hocko
2021-01-13 19:14 ` Vlastimil Babka
2021-01-13 22:37 ` Jann Horn
2021-01-13 22:37 ` Jann Horn
2021-01-14 9:04 ` Christoph Lameter
2021-01-14 9:04 ` Christoph Lameter
2021-01-21 17:21 ` Vlastimil Babka
2021-01-21 17:21 ` [RFC 1/2] mm, vmscan: add priority field to struct shrink_control Vlastimil Babka
2021-01-21 17:21 ` [RFC 2/2] mm, slub: add shrinker to reclaim cached slabs Vlastimil Babka
2021-01-22 0:48 ` Roman Gushchin
2021-01-26 12:06 ` Vlastimil Babka [this message]
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=51de513a-9c4e-35fa-fd04-977480ac50a0@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=cl@linux.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=shakeelb@google.com \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.