netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Abel Wu <wuyun.abel@bytedance.com>,
	Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	Shakeel Butt <shakeelb@google.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	Muchun Song <muchun.song@linux.dev>,
	Simon Horman <simon.horman@corigine.com>,
	 netdev@vger.kernel.org, linux-mm@kvack.org,
	cgroups@vger.kernel.org,  linux-kernel@vger.kernel.org
Subject: Re: Re: [PATCH net-next v5 2/3] sock: Always take memcg pressure into consideration
Date: Mon, 05 Jun 2023 10:27:47 +0200	[thread overview]
Message-ID: <727b1fb64d04deb8b2a9ae1fec4b51dafa1ff2b5.camel@redhat.com> (raw)
In-Reply-To: <6f67c3ca-5e73-d7ac-f32a-42a21d3ea576@bytedance.com>

On Mon, 2023-06-05 at 11:44 +0800, Abel Wu wrote:
> On 6/4/23 6:36 PM, Willem de Bruijn wrote:
> > On Fri, Jun 2, 2023 at 10:42 PM Shakeel Butt <shakeelb@google.com> wrote:
> > > 
> > > On Fri, Jun 02, 2023 at 04:11:34PM +0800, Abel Wu wrote:
> > > > The sk_under_memory_pressure() is called to check whether there is
> > > > memory pressure related to this socket. But now it ignores the net-
> > > > memcg's pressure if the proto of the socket doesn't care about the
> > > > global pressure, which may put burden on its memcg compaction or
> > > > reclaim path (also remember that socket memory is un-reclaimable).
> > > > 
> > > > So always check the memcg's vm status to alleviate memstalls when
> > > > it's in pressure.
> > > > 
> > > 
> > > This is interesting. UDP is the only protocol which supports memory
> > > accounting (i.e. udp_memory_allocated) but it does not define
> > > memory_pressure. In addition, it does have sysctl_udp_mem. So
> > > effectively UDP supports a hard limit and ignores memcg pressure at the
> > > moment. This patch will change its behavior to consider memcg pressure
> > > as well. I don't have any objection but let's get opinion of UDP
> > > maintainer.

Thanks for the head-up, I did not notice the side effect on UDP.

> 
> > So this commit only affects the only other protocol-independent
> > caller, __sk_mem_reduce_allocated, to possibly call
> > sk_leave_memory_pressure if now under the global limit.
> > 
> > What is the expected behavioral change in practice of this commit?
> 
> Be more conservative on sockmem alloc if under memcg pressure, to
> avoid worse memstall/latency.

I guess the above is for TCP sockets only, right? Or at least not for
UDP sockets?

If so, I think we should avoid change of behaviour for UDP - e.g.
keeping the initial 'if (!sk->sk_prot->memory_pressure)' in
sk_under_memory_pressure(), with some comments about the rationale for
future memory. That should preserve the whole patchset effect for other
protocols, right?

If instead you are also interested into UDP sockets under pressure, how
that is going to work? UDP sockets can reclaim memory only at send and
close time. A memcg under pressure could starve some sockets forever if
the the ones keeping the memory busy are left untouched.

Cheers,

Paolo


  reply	other threads:[~2023-06-05  8:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-02  8:11 [PATCH net-next v5 0/3] sock: Improve condition on sockmem pressure Abel Wu
2023-06-02  8:11 ` [PATCH net-next v5 1/3] net-memcg: Fold dependency into memcg pressure cond Abel Wu
2023-06-02 20:25   ` Shakeel Butt
2023-06-05 11:52     ` Abel Wu
2023-06-02  8:11 ` [PATCH net-next v5 2/3] sock: Always take memcg pressure into consideration Abel Wu
2023-06-02 20:41   ` Shakeel Butt
2023-06-04 10:36     ` Willem de Bruijn
2023-06-05  3:44       ` Abel Wu
2023-06-05  8:27         ` Paolo Abeni [this message]
2023-06-05  9:57           ` Abel Wu
2023-06-02  8:11 ` [PATCH net-next v5 3/3] sock: Fix misuse of sk_under_memory_pressure() Abel Wu
2023-06-02 20:53   ` Shakeel Butt
2023-06-05  8:34     ` Abel Wu
2023-06-06  8:39   ` kernel test robot

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=727b1fb64d04deb8b2a9ae1fec4b51dafa1ff2b5.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=shakeelb@google.com \
    --cc=simon.horman@corigine.com \
    --cc=vdavydov.dev@gmail.com \
    --cc=willemdebruijn.kernel@gmail.com \
    --cc=wuyun.abel@bytedance.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;
as well as URLs for NNTP newsgroup(s).