From: Yafang Shao <laoar.shao@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>, Martin Lau <kafai@fb.com>,
Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
john fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
jolsa@kernel.org, Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeelb@google.com>,
Muchun Song <songmuchun@bytedance.com>,
Andrew Morton <akpm@linux-foundation.org>,
netdev <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>
Subject: Re: [RFC PATCH bpf-next 10/15] bpf: Use bpf_map_pages_alloc in ringbuf
Date: Wed, 3 Aug 2022 21:27:59 +0800 [thread overview]
Message-ID: <CALOAHbBaQh38htnVg7sXrBEeCghe3RYL514xAqi_DhuHbOXMyw@mail.gmail.com> (raw)
In-Reply-To: <CAEf4BzYfpLG3X5b=stNBfX2KU1JOvFRucvQC_vUmg2yVK3JZ=Q@mail.gmail.com>
On Wed, Aug 3, 2022 at 2:00 AM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Tue, Aug 2, 2022 at 6:31 AM Yafang Shao <laoar.shao@gmail.com> wrote:
> >
> > On Tue, Aug 2, 2022 at 7:17 AM Andrii Nakryiko
> > <andrii.nakryiko@gmail.com> wrote:
> > >
> > > On Fri, Jul 29, 2022 at 8:23 AM Yafang Shao <laoar.shao@gmail.com> wrote:
> > > >
> > > > Introduce new helper bpf_map_pages_alloc() for this memory allocation.
> > > >
> > > > Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> > > > ---
> > > > include/linux/bpf.h | 4 ++++
> > > > kernel/bpf/ringbuf.c | 27 +++++++++------------------
> > > > kernel/bpf/syscall.c | 41 +++++++++++++++++++++++++++++++++++++++++
> > > > 3 files changed, 54 insertions(+), 18 deletions(-)
> > > >
> > >
> > > [...]
> > >
> > > > /* Each data page is mapped twice to allow "virtual"
> > > > * continuous read of samples wrapping around the end of ring
> > > > @@ -95,16 +95,10 @@ static struct bpf_ringbuf *bpf_ringbuf_area_alloc(struct bpf_map *map,
> > > > if (!pages)
> > > > return NULL;
> > > >
> > > > - for (i = 0; i < nr_pages; i++) {
> > > > - page = alloc_pages_node(numa_node, flags, 0);
> > > > - if (!page) {
> > > > - nr_pages = i;
> > > > - goto err_free_pages;
> > > > - }
> > > > - pages[i] = page;
> > > > - if (i >= nr_meta_pages)
> > > > - pages[nr_data_pages + i] = page;
> > > > - }
> > > > + ptr = bpf_map_pages_alloc(map, pages, nr_meta_pages, nr_data_pages,
> > > > + numa_node, flags, 0);
> > > > + if (!ptr)
> > >
> > > bpf_map_pages_alloc() has some weird and confusing interface. It fills
> > > out pages (second argument) and also returns pages as void *. Why not
> > > just return int error (0 or -ENOMEM)? You are discarding this ptr
> > > anyways.
> > >
> >
> > I will change it.
> >
> > >
> > > But also thinking some more, bpf_map_pages_alloc() is very ringbuf
> > > specific (which other map will have exactly the same meaning for
> > > nr_meta_pages and nr_data_pages, where we also allocate 2 *
> > > nr_data_pages, etc).
> > >
> > > I don't think it makes sense to expose it as a generic internal API.
> > > Why not keep all that inside kernel/bpf/ringbuf.c instead?
> > >
> >
> > Right, it is used in ringbuf.c only currently. I will keep it inside ringbuf.c.
> >
>
> In such case you might as well put pages = bpf_map_area_alloc(); part
> into this function and return struct page ** as a result, so that
> everything related to pages is handled as a single unit. And then
> bpf_map_pages_free() will free not just each individual page, but also
> struct page*[] array.
>
Good suggestion. I will do it.
> Also please call it something ringbuf specific, e.g.,
> bpf_ringbuf_pages_{alloc,free}()?
>
It Makes sense to me.
--
Regards
Yafang
next prev parent reply other threads:[~2022-08-03 13:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-29 15:23 [RFC PATCH bpf-next 00/15] bpf: Introduce selectable memcg for bpf map Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 01/15] bpf: Remove unneeded memset in queue_stack_map creation Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 02/15] bpf: Use bpf_map_area_free instread of kvfree Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 03/15] bpf: Make __GFP_NOWARN consistent in bpf map creation Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 04/15] bpf: Use bpf_map_area_alloc consistently on " Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 05/15] bpf: Introduce helpers for container of struct bpf_map Yafang Shao
2022-08-02 4:58 ` Alexei Starovoitov
2022-08-02 13:47 ` Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 06/15] bpf: Use bpf_map_container_alloc helpers in various bpf maps Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 07/15] bpf: Define bpf_map_get_memcg for !CONFIG_MEMCG_KMEM Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 08/15] bpf: Use scope-based charge for bpf_map_area_alloc Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 09/15] bpf: Use bpf_map_kzalloc in arraymap Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 10/15] bpf: Use bpf_map_pages_alloc in ringbuf Yafang Shao
2022-08-01 23:16 ` Andrii Nakryiko
2022-08-02 13:31 ` Yafang Shao
2022-08-02 18:00 ` Andrii Nakryiko
2022-08-03 13:27 ` Yafang Shao [this message]
2022-07-29 15:23 ` [RFC PATCH bpf-next 11/15] bpf: Use bpf_map_kvcalloc in bpf_local_storage Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 12/15] mm, memcg: Add new helper get_obj_cgroup_from_cgroup Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 13/15] bpf: Add new parameter into bpf_map_container_alloc Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 14/15] bpf: Add new map flag BPF_F_SELECTABLE_MEMCG Yafang Shao
2022-07-29 15:23 ` [RFC PATCH bpf-next 15/15] bpf: Introduce selectable memcg for bpf map Yafang Shao
2022-08-02 4:55 ` Alexei Starovoitov
2022-08-02 13:47 ` Yafang Shao
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=CALOAHbBaQh38htnVg7sXrBEeCghe3RYL514xAqi_DhuHbOXMyw@mail.gmail.com \
--to=laoar.shao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=hannes@cmpxchg.org \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=roman.gushchin@linux.dev \
--cc=sdf@google.com \
--cc=shakeelb@google.com \
--cc=songliubraving@fb.com \
--cc=songmuchun@bytedance.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox