From: Linus Torvalds <torvalds@linux-foundation.org>
To: Martin KaFai Lau <kafai@fb.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
David Miller <davem@davemloft.net>,
kernel-team@fb.com, Linux-Sparse <linux-sparse@vger.kernel.org>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
Netdev <netdev@vger.kernel.org>,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH bpf] bpf: Improve bucket_log calculation logic
Date: Fri, 7 Feb 2020 10:07:32 -0800 [thread overview]
Message-ID: <CAHk-=wieADOQcYkehVN7meevnd3jZrq06NkmyH9GGR==2rEpuQ@mail.gmail.com> (raw)
In-Reply-To: <20200207081810.3918919-1-kafai@fb.com>
On Fri, Feb 7, 2020 at 12:18 AM Martin KaFai Lau <kafai@fb.com> wrote:
>
> It was reported that the max_t, ilog2, and roundup_pow_of_two macros have
> exponential effects on the number of states in the sparse checker.
Patch looks good, but I'd like to point out that it's not just sparse.
You can see it with a simple
make net/core/bpf_sk_storage.i
grep 'smap->bucket_log = ' net/core/bpf_sk_storage.i | wc
and see the end result:
1 365071 2686974
That's one line (the assignment line) that is 2,686,974 characters in length.
Now, sparse does happen to react particularly badly to that (I didn't
look to why, but I suspect it's just that evaluating all the types
that don't actually ever end up getting used ends up being much more
expensive than it should be), but I bet it's not good for gcc either.
I do think this is a good test-case for sparse. Luc, have you looked
at what it is that then makes sparse use *so* much memory for this one
line?
Linus
next prev parent reply other threads:[~2020-02-07 18:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-07 8:18 [PATCH bpf] bpf: Improve bucket_log calculation logic Martin KaFai Lau
2020-02-07 8:18 ` Martin KaFai Lau
2020-02-07 13:07 ` Luc Van Oostenryck
2020-02-07 18:07 ` Linus Torvalds [this message]
2020-02-07 19:39 ` Linus Torvalds
2020-02-07 20:41 ` Luc Van Oostenryck
2020-02-07 21:22 ` Linus Torvalds
[not found] ` <20200208235459.xmliqf2ksbre53jj@ltop.local>
2020-02-09 0:58 ` Linus Torvalds
2020-02-09 12:19 ` Luc Van Oostenryck
2020-02-07 20:13 ` Alexei Starovoitov
2020-02-07 21:09 ` Linus Torvalds
2020-02-07 22:04 ` 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='CAHk-=wieADOQcYkehVN7meevnd3jZrq06NkmyH9GGR==2rEpuQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kafai@fb.com \
--cc=kernel-team@fb.com \
--cc=linux-sparse@vger.kernel.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=rdunlap@infradead.org \
/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.