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.
Signed-off-by: Abel Wu <wuyun.abel@bytedance.com>
---
include/net/sock.h | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 3f63253ee092..ad1895ffbc4a 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1411,13 +1411,11 @@ static inline bool sk_has_memory_pressure(const struct sock *sk)
static inline bool sk_under_memory_pressure(const struct sock *sk)
{
- if (!sk->sk_prot->memory_pressure)
- return false;
-
if (mem_cgroup_under_socket_pressure(sk->sk_memcg))
return true;
- return !!*sk->sk_prot->memory_pressure;
+ return sk->sk_prot->memory_pressure &&
+ *sk->sk_prot->memory_pressure;
}
static inline long
--
2.37.3+Willem
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.
> Signed-off-by: Abel Wu <wuyun.abel@bytedance.com>
> ---
> include/net/sock.h | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 3f63253ee092..ad1895ffbc4a 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1411,13 +1411,11 @@ static inline bool sk_has_memory_pressure(const struct sock *sk)
>
> static inline bool sk_under_memory_pressure(const struct sock *sk)
> {
> - if (!sk->sk_prot->memory_pressure)
> - return false;
> -
> if (mem_cgroup_under_socket_pressure(sk->sk_memcg))
> return true;
>
> - return !!*sk->sk_prot->memory_pressure;
> + return sk->sk_prot->memory_pressure &&
> + *sk->sk_prot->memory_pressure;
> }
>
> static inline long
> --
> 2.37.3
>
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.
Others have more experience with memory pressure on UDP, for the
record. Paolo worked on UDP memory pressure in
https://lore.kernel.org/netdev/cover.1579281705.git.pabeni@redhat.com/
It does seem odd to me to modify sk_under_memory_pressure only. See
for instance its use in __sk_mem_raise_allocated:
if (sk_has_memory_pressure(sk)) {
u64 alloc;
if (!sk_under_memory_pressure(sk))
return 1;
This is not even reached as sk_has_memory_pressure is false for 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?
> > Signed-off-by: Abel Wu <wuyun.abel@bytedance.com>
> > ---
> > include/net/sock.h | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index 3f63253ee092..ad1895ffbc4a 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -1411,13 +1411,11 @@ static inline bool sk_has_memory_pressure(const struct sock *sk)
> >
> > static inline bool sk_under_memory_pressure(const struct sock *sk)
> > {
> > - if (!sk->sk_prot->memory_pressure)
> > - return false;
> > -
> > if (mem_cgroup_under_socket_pressure(sk->sk_memcg))
> > return true;
> >
> > - return !!*sk->sk_prot->memory_pressure;
> > + return sk->sk_prot->memory_pressure &&
> > + *sk->sk_prot->memory_pressure;
> > }
> >
> > static inline long
> > --
> > 2.37.3
> >
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.
>
> Others have more experience with memory pressure on UDP, for the
> record. Paolo worked on UDP memory pressure in
> https://lore.kernel.org/netdev/cover.1579281705.git.pabeni@redhat.com/
>
> It does seem odd to me to modify sk_under_memory_pressure only. See
> for instance its use in __sk_mem_raise_allocated:
>
> if (sk_has_memory_pressure(sk)) {
> u64 alloc;
>
> if (!sk_under_memory_pressure(sk))
> return 1;
>
> This is not even reached as sk_has_memory_pressure is false for UDP.
I intended to make __sk_mem_raise_allocated() be aware of net-memcg
pressure instead of just this bit [1][2].
[1]
https://lore.kernel.org/lkml/20230523094652.49411-5-wuyun.abel@bytedance.com/
[2]
https://lore.kernel.org/lkml/20230523094652.49411-6-wuyun.abel@bytedance.com/
And TBH I am wondering why considering memcg's pressure here, as the
main part in this if statement is to allow the sockets that are below
average memory usage to raise from a *global* memory view, which seems
nothing to do with memcg.
> 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.
>
>
>>> Signed-off-by: Abel Wu <wuyun.abel@bytedance.com>
>>> ---
>>> include/net/sock.h | 6 ++----
>>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/net/sock.h b/include/net/sock.h
>>> index 3f63253ee092..ad1895ffbc4a 100644
>>> --- a/include/net/sock.h
>>> +++ b/include/net/sock.h
>>> @@ -1411,13 +1411,11 @@ static inline bool sk_has_memory_pressure(const struct sock *sk)
>>>
>>> static inline bool sk_under_memory_pressure(const struct sock *sk)
>>> {
>>> - if (!sk->sk_prot->memory_pressure)
>>> - return false;
>>> -
>>> if (mem_cgroup_under_socket_pressure(sk->sk_memcg))
>>> return true;
>>>
>>> - return !!*sk->sk_prot->memory_pressure;
>>> + return sk->sk_prot->memory_pressure &&
>>> + *sk->sk_prot->memory_pressure;
>>> }
>>>
>>> static inline long
>>> --
>>> 2.37.3
>>>
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
On 6/5/23 4:27 PM, Paolo Abeni wrote: > 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? Yes, I started off with TCP but wondering if it is applicable to the others too as the 'problem' sounds really generic to me. > > 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? Keeping the if statement as it is would imply the prot pressure as a master 'switch' to all kinds of pressure. IMHO this might hurt other protocols with pressure enabled if they are all used in one memcg which happens to be under vmpressure, IOW UDP allocations are given higher priority than others. > > 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. Yes.. And it starts to get me confused that why&when should the memcg pressure be used given that we don't want to put harsh constrains on sockmem even under memcg pressure. Thanks! Abel
© 2016 - 2026 Red Hat, Inc.