Re: [patch] mm, memcg: provide a stat to describe reclaimable memory
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: David Rientjes <rientjes@xxxxxxxxxx>
- Subject: Re: [patch] mm, memcg: provide a stat to describe reclaimable memory
- From: Chris Down <chris@xxxxxxxxxxxxxx>
- Date: Wed, 15 Jul 2020 14:10:48 +0100
- Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Yang Shi <shy828301@xxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxxxx>, Shakeel Butt <shakeelb@xxxxxxxxxx>, Yang Shi <yang.shi@xxxxxxxxxxxxxxxxx>, Roman Gushchin <guro@xxxxxx>, Greg Thelen <gthelen@xxxxxxxxxx>, Johannes Weiner <hannes@xxxxxxxxxxx>, Vladimir Davydov <vdavydov.dev@xxxxxxxxx>, cgroups@xxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx
- In-reply-to: <alpine.DEB.2.23.453.2007142018150.2667860@chino.kir.corp.google.com>
- References: <alpine.DEB.2.23.453.2007142018150.2667860@chino.kir.corp.google.com>
- User-agent: Mutt/1.14.6 (2020-07-11)
Hi David,
I'm somewhat against adding more metrics which try to approximate availability
of memory when we already know it not to generally manifest very well in
practice, especially since this *is* calculable by userspace (albeit with some
knowledge of mm internals). Users and applications often vastly overestimate
the reliability of these metrics, especially since they heavily depend on
transient page states and whatever reclaim efficacy happens to be achieved at
the time there is demand.
What do you intend to do with these metrics and how do you envisage other users
should use them? Is it not possible to rework the strategy to use pressure
information and/or workingset pressurisation instead?
Thanks,
Chris
[Index of Archives]
[Linux ARM Kernel]
[Linux ARM]
[Linux Omap]
[Fedora ARM]
[IETF Annouce]
[Bugtraq]
[Linux OMAP]
[Linux MIPS]
[eCos]
[Asterisk Internet PBX]
[Linux API]