Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 23 Jun 2022 11:42:59 +0200
From:   Michal Hocko <mhocko@suse.com>
To:     Yosry Ahmed <yosryahmed@google.com>
Cc:     Johannes Weiner <hannes@cmpxchg.org>,
        Roman Gushchin <roman.gushchin@linux.dev>,
        Shakeel Butt <shakeelb@google.com>,
        Muchun Song <songmuchun@bytedance.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Matthew Wilcox <willy@infradead.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        David Hildenbrand <david@redhat.com>,
        Miaohe Lin <linmiaohe@huawei.com>, NeilBrown <neilb@suse.de>,
        Alistair Popple <apopple@nvidia.com>,
        Suren Baghdasaryan <surenb@google.com>,
        Peter Xu <peterx@redhat.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Cgroups <cgroups@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: vmpressure: don't count userspace-induced reclaim as
 memory pressure
Message-ID: <YrQ1o3CeaZWhm+h4@dhcp22.suse.cz>
References: <20220623000530.1194226-1-yosryahmed@google.com>
 <YrQe5A+FXnbgOR1f@dhcp22.suse.cz>
 <CAJD7tkanavKpKrQr8-jA8pukgD7OY4eOwJRZufJ2NoThD12G+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJD7tkanavKpKrQr8-jA8pukgD7OY4eOwJRZufJ2NoThD12G+Q@mail.gmail.com>
Precedence: bulk

On Thu 23-06-22 01:35:59, Yosry Ahmed wrote:
> On Thu, Jun 23, 2022 at 1:05 AM Michal Hocko <mhocko@suse.com> 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.

These are good reasons to have this patch in your tree. But why is this
patch benefitial for the upstream kernel? It clearly adds some code and
some special casing which will add a maintenance overhead.
-- 
Michal Hocko
SUSE Labs