Messages in this thread | | | From | Yosry Ahmed <> | Date | Wed, 25 May 2022 13:31:42 -0700 | Subject | Re: [PATCH] memcg: provide reclaim stats via 'memory.reclaim' |
| |
On Wed, May 25, 2022 at 1:59 AM Michal Hocko <mhocko@suse.com> wrote: > > On Tue 24-05-22 12:01:01, Yosry Ahmed wrote: > > On Tue, May 24, 2022 at 4:45 AM Johannes Weiner <hannes@cmpxchg.org> wrote: > > > > > > On Mon, May 23, 2022 at 03:50:34PM -0700, Yosry Ahmed wrote: > > > > I think it might be useful to have a dedicated entry in memory.stat > > > > for proactively reclaimed memory. A case where this would be useful is > > > > tuning and evaluating userspace proactive reclaimers. For instance, if > > > > a userspace agent is asking the kernel to reclaim 100M, but it could > > > > only reclaim 10M, then most probably the proactive reclaimer is not > > > > using a good methodology to figure out how much memory do we need to > > > > reclaim. > > > > > > > > IMO this is more useful, and a superset of just reading the last > > > > reclaim request status through memory.reclaim (read stat before and > > > > after). > > > > > > +1 > > > > It might also be useful to have a breakdown of this by memory type: > > file, anon, or shrinkers. > > > > It would also fit in nicely with a potential type=file/anon/shrinker > > argument to memory.reclaim. Thoughts on this? > > Can we start simple and see what real usecases actually will need?
Agreed. Let's start with a single proactively reclaimed memory stat and then add subcategories if/when needed.
> -- > Michal Hocko > SUSE Labs
| |