On Thu, Jun 23, 2022 at 1:05 AM Michal Hocko <mhocko@xxxxxxxx> wrote:
>
> On Thu 23-06-22 00:05:30, Yosry Ahmed wrote:
> > Commit e22c6ed90aa9 ("mm: memcontrol: don't count limit-setting reclaim
> > as memory pressure") made sure that memory reclaim that is induced by
> > userspace (limit-setting, proactive reclaim, ..) is not counted as
> > memory pressure for the purposes of psi.
> >
> > Instead of counting psi inside try_to_free_mem_cgroup_pages(), callers
> > from try_charge() and reclaim_high() wrap the call to
> > try_to_free_mem_cgroup_pages() with psi handlers.
> >
> > However, vmpressure is still counted in these cases where reclaim is
> > directly induced by userspace. This patch makes sure vmpressure is not
> > counted in those operations, in the same way as psi. Since vmpressure
> > calls need to happen deeper within the reclaim path, the same approach
> > could not be followed. Hence, a new "controlled" flag is added to struct
> > scan_control to flag a reclaim operation that is controlled by
> > userspace. This flag is set by limit-setting and proactive reclaim
> > operations, and is used to count vmpressure correctly.
> >
> > To prevent future divergence of psi and vmpressure, commit e22c6ed90aa9
> > ("mm: memcontrol: don't count limit-setting reclaim as memory pressure")
> > is effectively reverted and the same flag is used to control psi as
> > well.
>
> Why do we need to add this is a legacy interface now? Are there any
> pre-existing users who realized this is bugging them? Please be more
> specific about the usecase.
Sorry if I wasn't clear enough. Unfortunately we still have userspace
workloads at Google that use vmpressure notifications.
In our internal version of memory.reclaim that we recently upstreamed,
we do not account vmpressure during proactive reclaim (similar to how
psi is handled upstream). We want to make sure this behavior also
exists in the upstream version so that consolidating them does not
break our users who rely on vmpressure and will start seeing increased
pressure due to proactive reclaim.
>
> --
> Michal Hocko
> SUSE Labs
