[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQK5t0YWGgdWmjiWX6vA0SjANrnf5x=yzu7PtDKpoK6cJQ@mail.gmail.com>
Date: Sat, 5 Nov 2022 09:20:23 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: "Ho-Ren (Jack) Chuang" <horenchuang@...edance.com>
Cc: Alexei Starovoitov <ast@...nel.org>, Hao Luo <haoluo@...gle.com>,
Jiri Olsa <jolsa@...nel.org>, Jiri Olsa <olsajiri@...il.com>,
Andrii Nakryiko <andrii@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
John Fastabend <john.fastabend@...il.com>,
Martin KaFai Lau <martin.lau@...ux.dev>,
Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...gle.com>,
Quentin Monnet <quentin@...valent.com>,
Mykola Lysenko <mykolal@...com>, Shuah Khan <shuah@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Tom Rix <trix@...hat.com>,
Joanne Koong <joannelkoong@...il.com>,
Kui-Feng Lee <kuifeng@...com>,
Lorenzo Bianconi <lorenzo@...nel.org>,
Maxim Mikityanskiy <maximmi@...dia.com>,
Hao Xiang <hao.xiang@...edance.com>,
Punit Agrawal <punit.agrawal@...edance.com>,
Yifei Ma <yifeima@...edance.com>,
Xiaoning Ding <xiaoning.ding@...edance.com>,
bpf <bpf@...r.kernel.org>, Ho-Ren Chuang <horenc@...edu>,
LKML <linux-kernel@...r.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
clang-built-linux <llvm@...ts.linux.dev>
Subject: Re: [PATCH bpf-next v1 0/4] Add BPF htab map's used size for monitoring
On Fri, Nov 4, 2022 at 7:52 PM Ho-Ren (Jack) Chuang
<horenchuang@...edance.com> wrote:
>
> Hello everyone,
>
> We have prepared patches to address an issue from a previous discussion.
> The previous discussion email thread is here: https://lore.kernel.org/all/CAADnVQLBt0snxv4bKwg1WKQ9wDFbaDCtZ03v1-LjOTYtsKPckQ@mail.gmail.com/
Rephrasing what was said earlier.
We're not keeping the count of elements in a preallocated hash map
and we are not going to add one.
The bpf prog needs to do the accounting on its own if it needs
this kind of statistics.
Keeping the count for non-prealloc is already significant performance
overhead. We don't trade performance for stats.
Powered by blists - more mailing lists