On Thu, Oct 27, 2022 at 01:43:24PM -0700, Yosry Ahmed wrote: > On Thu, Oct 27, 2022 at 7:15 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > > On Wed, Oct 26, 2022 at 07:41:21PM -0700, Yosry Ahmed wrote: > > > My 2c, if we care about direct reclaim as in reclaim that may stall > > > user space application allocations, then there are other reclaim > > > contexts that may pollute the direct reclaim stats. For instance, > > > proactive reclaim, or reclaim done by writing a limit lower than the > > > current usage to memory.max or memory.high, as they are not done in > > > the context of the application allocating memory. > > > > > > At Google, we have some internal direct reclaim memcg statistics, and > > > the way we handle this is by passing a flag from such contexts to > > > try_to_free_mem_cgroup_pages() in the reclaim_options arg. This flag > > > is echod into a scan_struct bit, which we then use to filter out > > > direct reclaim operations that actually cause latencies in user space > > > allocations. > > > > > > Perhaps something similar might be more generic here? I am not sure > > > what context khugepaged reclaims memory from, but I think it's not a > > > memcg context, so maybe we want to generalize the reclaim_options arg > > > to try_to_free_pages() or whatever interface khugepaged uses to free > > > memory. > > > > So at the /proc/vmstat level, I'm not sure it matters much because it > > doesn't count any cgroup_reclaim() activity. > > > > But at the cgroup level, it sure would be nice to split out proactive > > reclaim churn. Both in terms of not polluting direct reclaim counts, > > but also for *knowing* how much proactive reclaim is doing. > > > > Do you have separate counters for this? > > Not yet. Currently we only have the first part, not polluting direct > reclaim counts. > > We basically exclude reclaim coming from memory.reclaim, setting > memory.max/memory.limit_in_bytes, memory.high (on write, not hitting > the high limit), and memory.force_empty from direct reclaim stats. > > As for having a separate counter for proactive reclaim, do you think > it should be limited to reclaim coming from memory.reclaim (and > potentially memory.force_empty), or should it include reclaim coming > from limit-setting as well? A combined counter seems reasonable to me. We *have* used the limit knobs to drive proactive reclaim in production in the past, so it's not a stretch. And I can't think of a scenario where you'd like them to be separate. I could think of two ways of describing it: pgscan_user: User-requested reclaim. Could be confusing if we ever have an in-kernel proactive reclaim driver - unless that would then go to another counter (new or kswapd). pgscan_ext: Reclaim activity from extraordinary/external requests. External as in: outside the allocation context.
