From: Martin KaFai Lau <kafai@fb.com>
To: Joanne Koong <joannekoong@fb.com>
Cc: <bpf@vger.kernel.org>, <andrii@kernel.org>, <ast@kernel.org>,
<daniel@iogearbox.net>, <Kernel-team@fb.com>
Subject: Re: [PATCH v6 bpf-next 1/5] bpf: Add bloom filter map implementation
Date: Thu, 28 Oct 2021 23:40:22 -0700 [thread overview]
Message-ID: <20211029064022.7hz6wfzk5wnx4tv7@kafai-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <6d930e97-424d-393d-4731-ac8eda9e5156@fb.com>
On Thu, Oct 28, 2021 at 10:52:22PM -0700, Joanne Koong wrote:
> On 10/28/21 9:49 PM, Martin KaFai Lau wrote:
>
> > On Thu, Oct 28, 2021 at 08:17:23PM -0700, Joanne Koong wrote:
> > > On 10/28/21 2:14 PM, Martin KaFai Lau wrote:
> > >
> > > On Wed, Oct 27, 2021 at 04:45:00PM -0700, Joanne Koong wrote:
> > > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > index
> > > 31421c74ba08..50105e0b8fcc 100644 > --- a/include/linux/bpf.h > +++
> > > b/include/linux/bpf.h > @@ -169,6 +169,7 @@ struct bpf_map { The
> > > earlier context is copied here:
> > >
> > > struct bpf_map *inner_map_meta;
> > > #ifdef CONFIG_SECURITY
> > > void *security;
> > > #endif
> > >
> > > > u32 value_size; > u32 max_entries; > u32 map_flags; > + u64
> > > map_extra; /* any per-map-type extra fields */ There is a 4 byte
> > > hole before the new 'u64 map_extra'. Try to move
> > > it before map_flags
>
> Manually resuscitating your previous comment back into this email ^.
>
> After rebasing to the latest master, I'm not seeing a significant difference
> anymore with map_extra before/after max_flags. This is what I see when
> running "pahole vmlinux.o":
>
> With map_extra AFTER map_flags:
>
> struct bpf_map {
> const struct bpf_map_ops * ops __attribute__((__aligned__(64)));
> /* 0 8 */
> struct bpf_map * inner_map_meta; /* 8 8 */
> void * security; /* 16 8 */
> enum bpf_map_type map_type; /* 24 4 */
> u32 key_size; /* 28 4 */
> u32 value_size; /* 32 4 */
> u32 max_entries; /* 36 4 */
> u32 map_flags; /* 40 4 */
>
> /* XXX 4 bytes hole, try to pack */
>
> u64 map_extra; /* 48 8 */
> int spin_lock_off; /* 56 4 */
> int timer_off; /* 60 4 */
> /* --- cacheline 1 boundary (64 bytes) --- */
> u32 id; /* 64 4 */
> int numa_node; /* 68 4 */
> u32 btf_key_type_id; /* 72 4 */
> u32 btf_value_type_id; /* 76 4 */
> struct btf * btf; /* 80 8 */
> struct mem_cgroup * memcg; /* 88 8 */
> char name[16]; /* 96 16 */
> u32 btf_vmlinux_value_type_id; /* 112 4
> */
> bool bypass_spec_v1; /* 116 1 */
> bool frozen; /* 117 1 */
>
> /* XXX 10 bytes hole, try to pack */
>
> /* --- cacheline 2 boundary (128 bytes) --- */
> atomic64_t refcnt __attribute__((__aligned__(64)));
> /* 128 8 */
> atomic64_t usercnt; /* 136 8 */
> struct work_struct work; /* 144 72 */
> /* --- cacheline 3 boundary (192 bytes) was 24 bytes ago --- */
> struct mutex freeze_mutex; /* 216 144 */
> /* --- cacheline 5 boundary (320 bytes) was 40 bytes ago --- */
> u64 writecnt; /* 360 8 */
>
> /* size: 384, cachelines: 6, members: 26 */
> /* sum members: 354, holes: 2, sum holes: 14 */
> /* padding: 16 */
> /* forced alignments: 2, forced holes: 1, sum forced holes: 10 */
> } __attribute__((__aligned__(64)));
>
>
> With map_extra BEFORE map_flags:
>
> struct bpf_map {
> const struct bpf_map_ops * ops __attribute__((__aligned__(64)));
> /* 0 8 */
> struct bpf_map * inner_map_meta; /* 8 8 */
> void * security; /* 16 8 */
> enum bpf_map_type map_type; /* 24 4 */
> u32 key_size; /* 28 4 */
> u32 value_size; /* 32 4 */
> u32 max_entries; /* 36 4 */
> u64 map_extra; /* 40 8 */
> u32 map_flags; /* 48 4 */
> int spin_lock_off; /* 52 4 */
> int timer_off; /* 56 4 */
> u32 id; /* 60 4 */
> /* --- cacheline 1 boundary (64 bytes) --- */
> int numa_node; /* 64 4 */
> u32 btf_key_type_id; /* 68 4 */
> u32 btf_value_type_id; /* 72 4 */
>
> /* XXX 4 bytes hole, try to pack */
>
> struct btf * btf; /* 80 8 */
> struct mem_cgroup * memcg; /* 88 8 */
> char name[16]; /* 96 16 */
> u32 btf_vmlinux_value_type_id; /* 112 4
> */
> bool bypass_spec_v1; /* 116 1 */
> bool frozen; /* 117 1 */
>
> /* XXX 10 bytes hole, try to pack */
>
> /* --- cacheline 2 boundary (128 bytes) --- */
> atomic64_t refcnt __attribute__((__aligned__(64)));
> /* 128 8 */
> atomic64_t usercnt; /* 136 8 */
> struct work_struct work; /* 144 72 */
> /* --- cacheline 3 boundary (192 bytes) was 24 bytes ago --- */
> struct mutex freeze_mutex; /* 216 144 */
> /* --- cacheline 5 boundary (320 bytes) was 40 bytes ago --- */
> u64 writecnt; /* 360 8 */
>
> /* size: 384, cachelines: 6, members: 26 */
> /* sum members: 354, holes: 2, sum holes: 14 */
> /* padding: 16 */
> /* forced alignments: 2, forced holes: 1, sum forced holes: 10 */
> } __attribute__((__aligned__(64)));
>
>
> The main difference is that the "id" field is part of the 2nd cacheline when
> "map_extra" is after "map_flags", and is part of the 1st cacheline when
> "map_extra" is before "map_flags".
>
> Do you think it's still worth it to move "map_extra" to before "map_flags"?
It looks like there is an existing 4 byte hole. I would take this chance
to plunge it by using an existing 4 byte field. Something like this:
diff --git i/include/linux/bpf.h w/include/linux/bpf.h
index 50105e0b8fcc..0e07c659acd4 100644
--- i/include/linux/bpf.h
+++ w/include/linux/bpf.h
@@ -169,22 +169,22 @@ struct bpf_map {
u32 value_size;
u32 max_entries;
u32 map_flags;
- u64 map_extra; /* any per-map-type extra fields */
int spin_lock_off; /* >=0 valid offset, <0 error */
int timer_off; /* >=0 valid offset, <0 error */
u32 id;
int numa_node;
u32 btf_key_type_id;
u32 btf_value_type_id;
+ u32 btf_vmlinux_value_type_id;
+ u64 map_extra; /* any per-map-type extra fields */
struct btf *btf;
#ifdef CONFIG_MEMCG_KMEM
struct mem_cgroup *memcg;
#endif
char name[BPF_OBJ_NAME_LEN];
- u32 btf_vmlinux_value_type_id;
bool bypass_spec_v1;
bool frozen; /* write-once; write-protected by freeze_mutex */
- /* 22 bytes hole */
+ /* 14 bytes hole */
/* The 3rd and 4th cacheline with misc members to avoid false sharing
* particularly with refcounting.
next prev parent reply other threads:[~2021-10-29 6:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 23:44 [PATCH v6 bpf-next 0/5] Implement bloom filter map Joanne Koong
2021-10-27 23:45 ` [PATCH v6 bpf-next 1/5] bpf: Add bloom filter map implementation Joanne Koong
2021-10-28 18:15 ` Andrii Nakryiko
2021-10-29 0:15 ` Joanne Koong
2021-10-29 0:44 ` Andrii Nakryiko
2021-10-28 20:35 ` Alexei Starovoitov
2021-10-28 21:14 ` Martin KaFai Lau
2021-10-29 3:17 ` Joanne Koong
2021-10-29 4:49 ` Martin KaFai Lau
[not found] ` <6d930e97-424d-393d-4731-ac8eda9e5156@fb.com>
2021-10-29 6:40 ` Martin KaFai Lau [this message]
2021-10-27 23:45 ` [PATCH v6 bpf-next 2/5] libbpf: Add "map_extra" as a per-map-type extra flag Joanne Koong
2021-10-28 18:14 ` Andrii Nakryiko
2021-10-27 23:45 ` [PATCH v6 bpf-next 3/5] selftests/bpf: Add bloom filter map test cases Joanne Koong
2021-10-28 18:16 ` Andrii Nakryiko
2021-10-27 23:45 ` [PATCH v6 bpf-next 4/5] bpf/benchs: Add benchmark tests for bloom filter throughput + false positive Joanne Koong
2021-10-28 18:26 ` Andrii Nakryiko
2021-10-27 23:45 ` [PATCH v6 bpf-next 5/5] bpf/benchs: Add benchmarks for comparing hashmap lookups w/ vs. w/out bloom filter Joanne Koong
2021-10-28 22:10 ` [PATCH v6 bpf-next 0/5] Implement bloom filter map Martin KaFai Lau
2021-10-28 23:05 ` Alexei Starovoitov
2021-10-29 0:23 ` Joanne Koong
2021-10-29 0:30 ` Alexei Starovoitov
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=20211029064022.7hz6wfzk5wnx4tv7@kafai-mbp.dhcp.thefacebook.com \
--to=kafai@fb.com \
--cc=Kernel-team@fb.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=joannekoong@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;
as well as URLs for NNTP newsgroup(s).