[PATCH net] net-memcg: avoid stalls when under memory pressure

[PATCH net] net-memcg: avoid stalls when under memory pressure

[Jakub Kicinski]

As Shakeel explains the commit under Fixes had the unintended
side-effect of no longer pre-loading the cached memory allowance.
Even tho we previously dropped the first packet received when
over memory limit - the consecutive ones would get thru by using
the cache. The charging was happening in batches of 128kB, so
we'd let in 128kB (truesize) worth of packets per one drop.

After the change we no longer force charge, there will be no
cache filling side effects. This causes significant drops and
connection stalls for workloads which use a lot of page cache,
since we can't reclaim page cache under GFP_NOWAIT.

Some of the latency can be recovered by improving SACK reneg
handling but nowhere near enough to get back to the pre-5.15
performance (the application I'm experimenting with still
sees 5-10x worst latency).

Apply the suggested workaround of using GFP_ATOMIC. We will now
be more permissive than previously as we'll drop _no_ packets
in softirq when under pressure. But I can't think of any good
and simple way to address that within networking.

Link: https://lore.kernel.org/all/20221012163300.795e7b86@kernel.org/
Suggested-by: Shakeel Butt <shakeelb@google.com>
Fixes: 4b1327be9fe5 ("net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem()")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: weiwan@google.com
CC: shakeelb@google.com
CC: ncardwell@google.com
CC: ycheng@google.com
---
 include/net/sock.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index 9e464f6409a7..22f8bab583dd 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2585,7 +2585,7 @@ static inline gfp_t gfp_any(void)
 
 static inline gfp_t gfp_memcg_charge(void)
 {
-	return in_softirq() ? GFP_NOWAIT : GFP_KERNEL;
+	return in_softirq() ? GFP_ATOMIC : GFP_KERNEL;
 }
 
 static inline long sock_rcvtimeo(const struct sock *sk, bool noblock)
-- 
2.37.3

[PATCH net] net-memcg: avoid stalls when under memory pressure

[Jakub Kicinski]

As Shakeel explains the commit under Fixes had the unintended
side-effect of no longer pre-loading the cached memory allowance.
Even tho we previously dropped the first packet received when
over memory limit - the consecutive ones would get thru by using
the cache. The charging was happening in batches of 128kB, so
we'd let in 128kB (truesize) worth of packets per one drop.

After the change we no longer force charge, there will be no
cache filling side effects. This causes significant drops and
connection stalls for workloads which use a lot of page cache,
since we can't reclaim page cache under GFP_NOWAIT.

Some of the latency can be recovered by improving SACK reneg
handling but nowhere near enough to get back to the pre-5.15
performance (the application I'm experimenting with still
sees 5-10x worst latency).

Apply the suggested workaround of using GFP_ATOMIC. We will now
be more permissive than previously as we'll drop _no_ packets
in softirq when under pressure. But I can't think of any good
and simple way to address that within networking.

Link: https://lore.kernel.org/all/20221012163300.795e7b86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org/
Suggested-by: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Fixes: 4b1327be9fe5 ("net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem()")
Signed-off-by: Jakub Kicinski <kuba-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
CC: weiwan-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
CC: shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
CC: ncardwell-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
CC: ycheng-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
---
 include/net/sock.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index 9e464f6409a7..22f8bab583dd 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2585,7 +2585,7 @@ static inline gfp_t gfp_any(void)
 
 static inline gfp_t gfp_memcg_charge(void)
 {
-	return in_softirq() ? GFP_NOWAIT : GFP_KERNEL;
+	return in_softirq() ? GFP_ATOMIC : GFP_KERNEL;
 }
 
 static inline long sock_rcvtimeo(const struct sock *sk, bool noblock)
-- 
2.37.3

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[Shakeel Butt]

On Fri, Oct 21, 2022 at 9:03 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> As Shakeel explains the commit under Fixes had the unintended
> side-effect of no longer pre-loading the cached memory allowance.
> Even tho we previously dropped the first packet received when
> over memory limit - the consecutive ones would get thru by using
> the cache. The charging was happening in batches of 128kB, so
> we'd let in 128kB (truesize) worth of packets per one drop.
>
> After the change we no longer force charge, there will be no
> cache filling side effects. This causes significant drops and
> connection stalls for workloads which use a lot of page cache,
> since we can't reclaim page cache under GFP_NOWAIT.
>
> Some of the latency can be recovered by improving SACK reneg
> handling but nowhere near enough to get back to the pre-5.15
> performance (the application I'm experimenting with still
> sees 5-10x worst latency).
>
> Apply the suggested workaround of using GFP_ATOMIC. We will now
> be more permissive than previously as we'll drop _no_ packets
> in softirq when under pressure. But I can't think of any good
> and simple way to address that within networking.
>
> Link: https://lore.kernel.org/all/20221012163300.795e7b86@kernel.org/
> Suggested-by: Shakeel Butt <shakeelb@google.com>
> Fixes: 4b1327be9fe5 ("net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem()")
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: weiwan@google.com
> CC: shakeelb@google.com
> CC: ncardwell@google.com
> CC: ycheng@google.com
> ---
>  include/net/sock.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 9e464f6409a7..22f8bab583dd 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -2585,7 +2585,7 @@ static inline gfp_t gfp_any(void)
>
>  static inline gfp_t gfp_memcg_charge(void)
>  {
> -       return in_softirq() ? GFP_NOWAIT : GFP_KERNEL;
> +       return in_softirq() ? GFP_ATOMIC : GFP_KERNEL;
>  }
>

How about just using gfp_any() and we can remove gfp_memcg_charge()?

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[Eric Dumazet]

On Fri, Oct 21, 2022 at 9:26 AM Shakeel Butt <shakeelb@google.com> wrote:
>
> On Fri, Oct 21, 2022 at 9:03 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > As Shakeel explains the commit under Fixes had the unintended
> > side-effect of no longer pre-loading the cached memory allowance.
> > Even tho we previously dropped the first packet received when
> > over memory limit - the consecutive ones would get thru by using
> > the cache. The charging was happening in batches of 128kB, so
> > we'd let in 128kB (truesize) worth of packets per one drop.
> >
> > After the change we no longer force charge, there will be no
> > cache filling side effects. This causes significant drops and
> > connection stalls for workloads which use a lot of page cache,
> > since we can't reclaim page cache under GFP_NOWAIT.
> >
> > Some of the latency can be recovered by improving SACK reneg
> > handling but nowhere near enough to get back to the pre-5.15
> > performance (the application I'm experimenting with still
> > sees 5-10x worst latency).
> >
> > Apply the suggested workaround of using GFP_ATOMIC. We will now
> > be more permissive than previously as we'll drop _no_ packets
> > in softirq when under pressure. But I can't think of any good
> > and simple way to address that within networking.
> >
> > Link: https://lore.kernel.org/all/20221012163300.795e7b86@kernel.org/
> > Suggested-by: Shakeel Butt <shakeelb@google.com>
> > Fixes: 4b1327be9fe5 ("net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem()")
> > Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> > ---
> > CC: weiwan@google.com
> > CC: shakeelb@google.com
> > CC: ncardwell@google.com
> > CC: ycheng@google.com
> > ---
> >  include/net/sock.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index 9e464f6409a7..22f8bab583dd 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -2585,7 +2585,7 @@ static inline gfp_t gfp_any(void)
> >
> >  static inline gfp_t gfp_memcg_charge(void)
> >  {
> > -       return in_softirq() ? GFP_NOWAIT : GFP_KERNEL;
> > +       return in_softirq() ? GFP_ATOMIC : GFP_KERNEL;
> >  }
> >
>
> How about just using gfp_any() and we can remove gfp_memcg_charge()?

How about keeping gfp_memcg_charge() and adding a comment on its intent ?

gfp_any() is very generic :/

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[Eric Dumazet]

On Fri, Oct 21, 2022 at 9:26 AM Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>
> On Fri, Oct 21, 2022 at 9:03 AM Jakub Kicinski <kuba-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >
> > As Shakeel explains the commit under Fixes had the unintended
> > side-effect of no longer pre-loading the cached memory allowance.
> > Even tho we previously dropped the first packet received when
> > over memory limit - the consecutive ones would get thru by using
> > the cache. The charging was happening in batches of 128kB, so
> > we'd let in 128kB (truesize) worth of packets per one drop.
> >
> > After the change we no longer force charge, there will be no
> > cache filling side effects. This causes significant drops and
> > connection stalls for workloads which use a lot of page cache,
> > since we can't reclaim page cache under GFP_NOWAIT.
> >
> > Some of the latency can be recovered by improving SACK reneg
> > handling but nowhere near enough to get back to the pre-5.15
> > performance (the application I'm experimenting with still
> > sees 5-10x worst latency).
> >
> > Apply the suggested workaround of using GFP_ATOMIC. We will now
> > be more permissive than previously as we'll drop _no_ packets
> > in softirq when under pressure. But I can't think of any good
> > and simple way to address that within networking.
> >
> > Link: https://lore.kernel.org/all/20221012163300.795e7b86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org/
> > Suggested-by: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > Fixes: 4b1327be9fe5 ("net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem()")
> > Signed-off-by: Jakub Kicinski <kuba-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > ---
> > CC: weiwan-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
> > CC: shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
> > CC: ncardwell-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
> > CC: ycheng-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
> > ---
> >  include/net/sock.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index 9e464f6409a7..22f8bab583dd 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -2585,7 +2585,7 @@ static inline gfp_t gfp_any(void)
> >
> >  static inline gfp_t gfp_memcg_charge(void)
> >  {
> > -       return in_softirq() ? GFP_NOWAIT : GFP_KERNEL;
> > +       return in_softirq() ? GFP_ATOMIC : GFP_KERNEL;
> >  }
> >
>
> How about just using gfp_any() and we can remove gfp_memcg_charge()?

How about keeping gfp_memcg_charge() and adding a comment on its intent ?

gfp_any() is very generic :/

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[Shakeel Butt]

On Fri, Oct 21, 2022 at 9:28 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Fri, Oct 21, 2022 at 9:26 AM Shakeel Butt <shakeelb@google.com> wrote:
> >
> > On Fri, Oct 21, 2022 at 9:03 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > >
> > > As Shakeel explains the commit under Fixes had the unintended
> > > side-effect of no longer pre-loading the cached memory allowance.
> > > Even tho we previously dropped the first packet received when
> > > over memory limit - the consecutive ones would get thru by using
> > > the cache. The charging was happening in batches of 128kB, so
> > > we'd let in 128kB (truesize) worth of packets per one drop.
> > >
> > > After the change we no longer force charge, there will be no
> > > cache filling side effects. This causes significant drops and
> > > connection stalls for workloads which use a lot of page cache,
> > > since we can't reclaim page cache under GFP_NOWAIT.
> > >
> > > Some of the latency can be recovered by improving SACK reneg
> > > handling but nowhere near enough to get back to the pre-5.15
> > > performance (the application I'm experimenting with still
> > > sees 5-10x worst latency).
> > >
> > > Apply the suggested workaround of using GFP_ATOMIC. We will now
> > > be more permissive than previously as we'll drop _no_ packets
> > > in softirq when under pressure. But I can't think of any good
> > > and simple way to address that within networking.
> > >
> > > Link: https://lore.kernel.org/all/20221012163300.795e7b86@kernel.org/
> > > Suggested-by: Shakeel Butt <shakeelb@google.com>
> > > Fixes: 4b1327be9fe5 ("net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem()")
> > > Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> > > ---
> > > CC: weiwan@google.com
> > > CC: shakeelb@google.com
> > > CC: ncardwell@google.com
> > > CC: ycheng@google.com
> > > ---
> > >  include/net/sock.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/net/sock.h b/include/net/sock.h
> > > index 9e464f6409a7..22f8bab583dd 100644
> > > --- a/include/net/sock.h
> > > +++ b/include/net/sock.h
> > > @@ -2585,7 +2585,7 @@ static inline gfp_t gfp_any(void)
> > >
> > >  static inline gfp_t gfp_memcg_charge(void)
> > >  {
> > > -       return in_softirq() ? GFP_NOWAIT : GFP_KERNEL;
> > > +       return in_softirq() ? GFP_ATOMIC : GFP_KERNEL;
> > >  }
> > >
> >
> > How about just using gfp_any() and we can remove gfp_memcg_charge()?
>
> How about keeping gfp_memcg_charge() and adding a comment on its intent ?
>
> gfp_any() is very generic :/

SGTM.

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[Shakeel Butt]

On Fri, Oct 21, 2022 at 9:28 AM Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>
> On Fri, Oct 21, 2022 at 9:26 AM Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > On Fri, Oct 21, 2022 at 9:03 AM Jakub Kicinski <kuba-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > >
> > > As Shakeel explains the commit under Fixes had the unintended
> > > side-effect of no longer pre-loading the cached memory allowance.
> > > Even tho we previously dropped the first packet received when
> > > over memory limit - the consecutive ones would get thru by using
> > > the cache. The charging was happening in batches of 128kB, so
> > > we'd let in 128kB (truesize) worth of packets per one drop.
> > >
> > > After the change we no longer force charge, there will be no
> > > cache filling side effects. This causes significant drops and
> > > connection stalls for workloads which use a lot of page cache,
> > > since we can't reclaim page cache under GFP_NOWAIT.
> > >
> > > Some of the latency can be recovered by improving SACK reneg
> > > handling but nowhere near enough to get back to the pre-5.15
> > > performance (the application I'm experimenting with still
> > > sees 5-10x worst latency).
> > >
> > > Apply the suggested workaround of using GFP_ATOMIC. We will now
> > > be more permissive than previously as we'll drop _no_ packets
> > > in softirq when under pressure. But I can't think of any good
> > > and simple way to address that within networking.
> > >
> > > Link: https://lore.kernel.org/all/20221012163300.795e7b86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org/
> > > Suggested-by: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > > Fixes: 4b1327be9fe5 ("net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem()")
> > > Signed-off-by: Jakub Kicinski <kuba-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > ---
> > > CC: weiwan-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
> > > CC: shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
> > > CC: ncardwell-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
> > > CC: ycheng-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
> > > ---
> > >  include/net/sock.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/net/sock.h b/include/net/sock.h
> > > index 9e464f6409a7..22f8bab583dd 100644
> > > --- a/include/net/sock.h
> > > +++ b/include/net/sock.h
> > > @@ -2585,7 +2585,7 @@ static inline gfp_t gfp_any(void)
> > >
> > >  static inline gfp_t gfp_memcg_charge(void)
> > >  {
> > > -       return in_softirq() ? GFP_NOWAIT : GFP_KERNEL;
> > > +       return in_softirq() ? GFP_ATOMIC : GFP_KERNEL;
> > >  }
> > >
> >
> > How about just using gfp_any() and we can remove gfp_memcg_charge()?
>
> How about keeping gfp_memcg_charge() and adding a comment on its intent ?
>
> gfp_any() is very generic :/

SGTM.

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[Jakub Kicinski]

On Fri, 21 Oct 2022 09:34:20 -0700 Shakeel Butt wrote:
> > > How about just using gfp_any() and we can remove gfp_memcg_charge()?  
> >
> > How about keeping gfp_memcg_charge() and adding a comment on its intent ?
> >
> > gfp_any() is very generic :/  

That was my thinking, and I'm not sure what I could put in a comment.
Wouldn't it be some mix of words 'flags', 'memory', 'cgroup' and
'charge'... which is just spelling out the name of the function? 

I mean:

	/* Alloc flags for passing to cgroup socket memory charging */

does not add much value, right? 

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[Jakub Kicinski]

On Fri, 21 Oct 2022 09:34:20 -0700 Shakeel Butt wrote:
> > > How about just using gfp_any() and we can remove gfp_memcg_charge()?  
> >
> > How about keeping gfp_memcg_charge() and adding a comment on its intent ?
> >
> > gfp_any() is very generic :/  

That was my thinking, and I'm not sure what I could put in a comment.
Wouldn't it be some mix of words 'flags', 'memory', 'cgroup' and
'charge'... which is just spelling out the name of the function? 

I mean:

	/* Alloc flags for passing to cgroup socket memory charging */

does not add much value, right? 

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[Shakeel Butt]

On Fri, Oct 21, 2022 at 10:40 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 21 Oct 2022 09:34:20 -0700 Shakeel Butt wrote:
> > > > How about just using gfp_any() and we can remove gfp_memcg_charge()?
> > >
> > > How about keeping gfp_memcg_charge() and adding a comment on its intent ?
> > >
> > > gfp_any() is very generic :/
>
> That was my thinking, and I'm not sure what I could put in a comment.
> Wouldn't it be some mix of words 'flags', 'memory', 'cgroup' and
> 'charge'... which is just spelling out the name of the function?
>
> I mean:
>
>         /* Alloc flags for passing to cgroup socket memory charging */
>
> does not add much value, right?

Yeah I agree. Let's just go with the original patch.

You can add:

Acked-by: Shakeel Butt <shakeelb@google.com>

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[Roman Gushchin]

On Fri, Oct 21, 2022 at 09:03:04AM -0700, Jakub Kicinski wrote:
> As Shakeel explains the commit under Fixes had the unintended
> side-effect of no longer pre-loading the cached memory allowance.
> Even tho we previously dropped the first packet received when
> over memory limit - the consecutive ones would get thru by using
> the cache. The charging was happening in batches of 128kB, so
> we'd let in 128kB (truesize) worth of packets per one drop.
> 
> After the change we no longer force charge, there will be no
> cache filling side effects. This causes significant drops and
> connection stalls for workloads which use a lot of page cache,
> since we can't reclaim page cache under GFP_NOWAIT.
> 
> Some of the latency can be recovered by improving SACK reneg
> handling but nowhere near enough to get back to the pre-5.15
> performance (the application I'm experimenting with still
> sees 5-10x worst latency).
> 
> Apply the suggested workaround of using GFP_ATOMIC. We will now
> be more permissive than previously as we'll drop _no_ packets
> in softirq when under pressure. But I can't think of any good
> and simple way to address that within networking.
> 
> Link: https://lore.kernel.org/all/20221012163300.795e7b86@kernel.org/
> Suggested-by: Shakeel Butt <shakeelb@google.com>
> Fixes: 4b1327be9fe5 ("net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem()")
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Acked-by: Roman Gushchin <roman.gushchin@linux.dev>

Thanks!

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[Roman Gushchin]

On Fri, Oct 21, 2022 at 09:03:04AM -0700, Jakub Kicinski wrote:
> As Shakeel explains the commit under Fixes had the unintended
> side-effect of no longer pre-loading the cached memory allowance.
> Even tho we previously dropped the first packet received when
> over memory limit - the consecutive ones would get thru by using
> the cache. The charging was happening in batches of 128kB, so
> we'd let in 128kB (truesize) worth of packets per one drop.
> 
> After the change we no longer force charge, there will be no
> cache filling side effects. This causes significant drops and
> connection stalls for workloads which use a lot of page cache,
> since we can't reclaim page cache under GFP_NOWAIT.
> 
> Some of the latency can be recovered by improving SACK reneg
> handling but nowhere near enough to get back to the pre-5.15
> performance (the application I'm experimenting with still
> sees 5-10x worst latency).
> 
> Apply the suggested workaround of using GFP_ATOMIC. We will now
> be more permissive than previously as we'll drop _no_ packets
> in softirq when under pressure. But I can't think of any good
> and simple way to address that within networking.
> 
> Link: https://lore.kernel.org/all/20221012163300.795e7b86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org/
> Suggested-by: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Fixes: 4b1327be9fe5 ("net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem()")
> Signed-off-by: Jakub Kicinski <kuba-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Acked-by: Roman Gushchin <roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>

Thanks!

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 21 Oct 2022 09:03:04 -0700 you wrote:
> As Shakeel explains the commit under Fixes had the unintended
> side-effect of no longer pre-loading the cached memory allowance.
> Even tho we previously dropped the first packet received when
> over memory limit - the consecutive ones would get thru by using
> the cache. The charging was happening in batches of 128kB, so
> we'd let in 128kB (truesize) worth of packets per one drop.
> 
> [...]

Here is the summary with links:
  - [net] net-memcg: avoid stalls when under memory pressure
    https://git.kernel.org/netdev/net/c/720ca52bcef2

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net] net-memcg: avoid stalls when under memory pressure

[patchwork-bot+netdevbpf-DgEjT+Ai2ygdnm+yROfE0A]

Hello:

This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:

On Fri, 21 Oct 2022 09:03:04 -0700 you wrote:
> As Shakeel explains the commit under Fixes had the unintended
> side-effect of no longer pre-loading the cached memory allowance.
> Even tho we previously dropped the first packet received when
> over memory limit - the consecutive ones would get thru by using
> the cache. The charging was happening in batches of 128kB, so
> we'd let in 128kB (truesize) worth of packets per one drop.
> 
> [...]

Here is the summary with links:
  - [net] net-memcg: avoid stalls when under memory pressure
    https://git.kernel.org/netdev/net/c/720ca52bcef2

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html