From: Shakeel Butt <shakeelb@google.com>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: Michal Hocko <mhocko@suse.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
Date: Wed, 29 Jun 2022 18:07:00 -0700 [thread overview]
Message-ID: <CALvZod68WdrXEmBpOkadhB5GPYmCXaDZzXH=yyGOCAjFRn4NDQ@mail.gmail.com> (raw)
In-Reply-To: <CAJD7tkYemNQqu_O2nYG3cqxPWGELvc6Lh5i+KKNCtv6cgSPmdA@mail.gmail.com>
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.
next prev parent reply other threads:[~2022-06-30 1:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-23 0:05 Yosry Ahmed
2022-06-23 0:16 ` Andrew Morton
2022-06-23 0:24 ` Yosry Ahmed
2022-06-23 8:05 ` Michal Hocko
2022-06-23 8:35 ` Yosry Ahmed
2022-06-23 9:42 ` Michal Hocko
2022-06-23 16:22 ` Yosry Ahmed
2022-06-23 16:37 ` Michal Hocko
2022-06-23 16:42 ` Shakeel Butt
2022-06-23 16:49 ` Yosry Ahmed
2022-06-23 17:04 ` Michal Hocko
2022-06-23 17:26 ` Yosry Ahmed
2022-06-24 22:10 ` Suren Baghdasaryan
2022-06-24 22:13 ` Yosry Ahmed
2022-06-24 22:41 ` Suren Baghdasaryan
2022-06-27 8:25 ` Michal Hocko
2022-06-27 8:39 ` Yosry Ahmed
2022-06-27 9:20 ` Michal Hocko
2022-06-27 9:39 ` Yosry Ahmed
2022-06-27 12:31 ` Michal Hocko
2022-06-27 17:03 ` Yosry Ahmed
2022-06-30 1:07 ` Shakeel Butt [this message]
2022-06-30 2:08 ` Yosry Ahmed
2022-06-30 8:22 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALvZod68WdrXEmBpOkadhB5GPYmCXaDZzXH=yyGOCAjFRn4NDQ@mail.gmail.com' \
--to=shakeelb@google.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=cgroups@vger.kernel.org \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=neilb@suse.de \
--cc=peterx@redhat.com \
--cc=roman.gushchin@linux.dev \
--cc=songmuchun@bytedance.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=yosryahmed@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox