All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Yafang Shao <laoar.shao@gmail.com>,
	ast@kernel.org, andrii@kernel.org, kafai@fb.com,
	songliubraving@fb.com, yhs@fb.com, john.fastabend@gmail.com,
	kpsingh@kernel.org, quentin@isovalent.com
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
	Roman Gushchin <roman.gushchin@linux.dev>
Subject: Re: [PATCH bpf-next 1/4] bpf: Make non-preallocated allocation low priority
Date: Thu, 30 Jun 2022 23:47:00 +0200	[thread overview]
Message-ID: <ede2c8ea-693d-fe70-12a2-bf8ccca97eb0@iogearbox.net> (raw)
In-Reply-To: <20220629154832.56986-2-laoar.shao@gmail.com>

Hi Yafang,

On 6/29/22 5:48 PM, Yafang Shao wrote:
> GFP_ATOMIC doesn't cooperate well with memcg pressure so far, especially
> if we allocate too much GFP_ATOMIC memory. For example, when we set the
> memcg limit to limit a non-preallocated bpf memory, the GFP_ATOMIC can
> easily break the memcg limit by force charge. So it is very dangerous to
> use GFP_ATOMIC in non-preallocated case. One way to make it safe is to
> remove __GFP_HIGH from GFP_ATOMIC, IOW, use (__GFP_ATOMIC |
> __GFP_KSWAPD_RECLAIM) instead, then it will be limited if we allocate
> too much memory.
> 
> We introduced BPF_F_NO_PREALLOC is because full map pre-allocation is
> too memory expensive for some cases. That means removing __GFP_HIGH
> doesn't break the rule of BPF_F_NO_PREALLOC, but has the same goal with
> it-avoiding issues caused by too much memory. So let's remove it.
> 
> __GFP_KSWAPD_RECLAIM doesn't cooperate well with memcg pressure neither
> currently. But the memcg code can be improved to make
> __GFP_KSWAPD_RECLAIM work well under memcg pressure.

Ok, but could you also explain in commit desc why it's a specific problem
to BPF hashtab?

Afaik, there is plenty of other code using GFP_ATOMIC | __GFP_NOWARN outside
of BPF e.g. under net/, so it's a generic memcg problem?

Why are lpm trie and local storage map for BPF not affected (at least I don't
see them covered in the patch)?

Thanks,
Daniel

> It also fixes a typo in the comment.
> 
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> Cc: Roman Gushchin <roman.gushchin@linux.dev>
> ---
>   kernel/bpf/hashtab.c | 8 +++++---
>   1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 17fb69c0e0dc..9d4559a1c032 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -61,7 +61,7 @@
>    *
>    * As regular device interrupt handlers and soft interrupts are forced into
>    * thread context, the existing code which does
> - *   spin_lock*(); alloc(GPF_ATOMIC); spin_unlock*();
> + *   spin_lock*(); alloc(GFP_ATOMIC); spin_unlock*();
>    * just works.
>    *
>    * In theory the BPF locks could be converted to regular spinlocks as well,
> @@ -978,7 +978,8 @@ static struct htab_elem *alloc_htab_elem(struct bpf_htab *htab, void *key,
>   				goto dec_count;
>   			}
>   		l_new = bpf_map_kmalloc_node(&htab->map, htab->elem_size,
> -					     GFP_ATOMIC | __GFP_NOWARN,
> +					     __GFP_ATOMIC | __GFP_NOWARN |
> +					     __GFP_KSWAPD_RECLAIM,
>   					     htab->map.numa_node);
>   		if (!l_new) {
>   			l_new = ERR_PTR(-ENOMEM);
> @@ -996,7 +997,8 @@ static struct htab_elem *alloc_htab_elem(struct bpf_htab *htab, void *key,
>   		} else {
>   			/* alloc_percpu zero-fills */
>   			pptr = bpf_map_alloc_percpu(&htab->map, size, 8,
> -						    GFP_ATOMIC | __GFP_NOWARN);
> +						    __GFP_ATOMIC | __GFP_NOWARN |
> +						    __GFP_KSWAPD_RECLAIM);
>   			if (!pptr) {
>   				kfree(l_new);
>   				l_new = ERR_PTR(-ENOMEM);
> 


  reply	other threads:[~2022-06-30 21:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-29 15:48 [PATCH bpf-next 0/4] bpf: Minor fixes Yafang Shao
2022-06-29 15:48 ` [PATCH bpf-next 1/4] bpf: Make non-preallocated allocation low priority Yafang Shao
2022-06-30 21:47   ` Daniel Borkmann [this message]
2022-07-02  2:30     ` Yafang Shao
2022-07-02  4:14     ` Roman Gushchin
2022-07-02 15:08       ` Yafang Shao
2022-07-02  3:54   ` Roman Gushchin
2022-06-29 15:48 ` [PATCH bpf-next 2/4] bpf: Warn on non-preallocated case for missed trace types Yafang Shao
2022-06-29 15:48 ` [PATCH bpf-next 3/4] bpf: Don't do preempt check when migrate is disabled Yafang Shao
2022-06-30 20:43   ` Hao Luo
2022-07-02  2:34     ` Yafang Shao
2022-06-29 15:48 ` [PATCH bpf-next 4/4] bpftool: Show also the name of type BPF_OBJ_LINK Yafang Shao
2022-06-29 16:22   ` Quentin Monnet
2022-06-30 21:55     ` Daniel Borkmann

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=ede2c8ea-693d-fe70-12a2-bf8ccca97eb0@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=quentin@isovalent.com \
    --cc=roman.gushchin@linux.dev \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.