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, 30 Jun 2022 10:22:19 +0200
From:   Michal Hocko <mhocko@suse.com>
To:     Yosry Ahmed <yosryahmed@google.com>
Cc:     Shakeel Butt <shakeelb@google.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Roman Gushchin <roman.gushchin@linux.dev>,
        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: <Yr1dOxHo0HsyG2X7@dhcp22.suse.cz>
References: <YrSdFy3qYdG+rGR6@dhcp22.suse.cz>
 <CAJD7tkZNEtzJMDsLMHuNHkxFfurS37UuK=zFcPCkOkWfN-dbJQ@mail.gmail.com>
 <YrlpcdgF1HzA7bHS@dhcp22.suse.cz>
 <CAJD7tkYVy2uNwaPiiJdPKT5P_O-9WgxD68iFJ6vw=TLJcQV3Ag@mail.gmail.com>
 <Yrl2T632Vfv8QGPn@dhcp22.suse.cz>
 <CAJD7tkZzwzHq7Q7KKUdVSdO4LWTPkrGprp0Q-ze_SWhUd_mTMw@mail.gmail.com>
 <YrmjH2FZF7iNn8da@dhcp22.suse.cz>
 <CAJD7tkYemNQqu_O2nYG3cqxPWGELvc6Lh5i+KKNCtv6cgSPmdA@mail.gmail.com>
 <CALvZod68WdrXEmBpOkadhB5GPYmCXaDZzXH=yyGOCAjFRn4NDQ@mail.gmail.com>
 <CAJD7tkZeySa9V+nuoGfmugrOcxaiaXFspPKLkgTFkvsrri=J3g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJD7tkZeySa9V+nuoGfmugrOcxaiaXFspPKLkgTFkvsrri=J3g@mail.gmail.com>
Precedence: bulk

On Wed 29-06-22 19:08:42, Yosry Ahmed wrote:
> On Wed, Jun 29, 2022 at 6:07 PM Shakeel Butt <shakeelb@google.com> wrote:
> >
> > On Mon, Jun 27, 2022 at 10:04 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> > >
> > > On Mon, Jun 27, 2022 at 5:31 AM Michal Hocko <mhocko@suse.com> wrote:
> > > >
> > [...]
> > > >
> > > > I can see clear arguments for memory.reclaim opt out for vmpressure
> > > > because we have established that this is not a measure to express a
> > > > memory pressure on the cgroup.
> > > >
> > > > Max/High are less clear to me, TBH. I do understand reasoning for PSI
> > > > exclusion because considering the calling process to be stalled and
> > > > non-productive is misleading. It just does its work so in a way it is
> > > > a productive time in the end. For the vmpressure, which measures how
> > > > hard/easy it is to reclaim memory why this should special for this
> > > > particular reclaim?
> > > >
> > > > Again, an explanation of the effect on the socket pressure could give a
> > > > better picture. Say that I somebody reduces the limit (hard/high) and it
> > > > takes quite some effort to shrink the consumption down. Should the
> > > > networking layer react to that in any way or should it wait for the
> > > > active allocation during that process to find that out?
> > >
> > > I am out of my depth here. Any answer on my side would be purely
> > > speculation at this point. Shakeel, can you help us here or tag some
> > > networking people?
> >
> > So, the effect of returning true from mem_cgroup_under_socket_pressure() are:
> >
> > 1. Reducing send and receive buffers of the current socket.
> > 2. May drop packets on the rx path.
> > 3. May throttle current thread on the tx path.
> >
> > Now regarding the behavior from the reclaim due to reducing max or
> > high, I think the kernel should not ignore vmpressure. Please note
> > that unlike PSI which is associated with the current process,
> > vmpressure is associated with the target memcg. So, any reclaim on
> > that memcg due to real shortage of memory should not be ignored. That
> > reclaim can be global reclaim or limit reclaim of ancestor or itself
> > or reclaim due to lowering the limit of ancestor or itself.
> 
> So it seems like we should only ignore vmpressure for proactive
> reclaim (aka memory.reclaim).
> 
> Michal, let me know what you think here, I can drop psi and
> limit-setting changes in v3 and basically just ignore vmpressure for
> memory.reclaim (MEMCG_RECLAIM_PROACTIVE / sc->proactive instead of
> MEMCG_RECLAIM_CONTROLLED / sc->controlled maybe).

Yes, that makes much more sense to me.

-- 
Michal Hocko
SUSE Labs