bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).