Messages in this thread | | | Date | Thu, 2 Jun 2022 11:29:09 +0800 | Subject | Re: Re: Re: [PATCH v4 2/2] selftest/bpf/benchs: Add bpf_map benchmark | From | Feng Zhou <> |
| |
在 2022/6/1 下午7:37, Alexei Starovoitov 写道: > On Wed, Jun 1, 2022 at 1:17 PM Feng Zhou <zhoufeng.zf@bytedance.com> wrote: >> 在 2022/6/1 下午5:53, Alexei Starovoitov 写道: >>> On Wed, Jun 1, 2022 at 10:42 AM Feng zhou <zhoufeng.zf@bytedance.com> wrote: >>>> +struct { >>>> + __uint(type, BPF_MAP_TYPE_HASH); >>>> + __type(key, u32); >>>> + __type(value, u64); >>>> + __uint(max_entries, MAX_ENTRIES); >>>> +} hash_map_bench SEC(".maps"); >>>> + >>>> +u64 __attribute__((__aligned__(256))) percpu_time[256]; >>> aligned 256 ? >>> What is the point? >> I didn't think too much about it here, just referenced it from >> tools/testing/selftests/bpf/progs/bloom_filter_bench.c >> >>>> +u64 nr_loops; >>>> + >>>> +static int loop_update_callback(__u32 index, u32 *key) >>>> +{ >>>> + u64 init_val = 1; >>>> + >>>> + bpf_map_update_elem(&hash_map_bench, key, &init_val, BPF_ANY); >>>> + return 0; >>>> +} >>>> + >>>> +SEC("fentry/" SYS_PREFIX "sys_getpgid") >>>> +int benchmark(void *ctx) >>>> +{ >>>> + u32 key = bpf_get_prandom_u32() % MAX_ENTRIES + MAX_ENTRIES; >>> What is the point of random ? >>> just key = MAX_ENTRIES would be the same, no? >>> or key = -1 ? >> If all threads on different cpu trigger sys_getpgid and lookup the same >> key, it will cause >> "ret = htab_lock_bucket(htab, b, hash, &flags);" >> the lock competition here is fierce, and unnecessary overhead is >> introduced, >> and I don't want it to interfere with the test. > I see. > but using random leaves it to chance. > Use cpu+max_entries then?
Ok, will do. Thanks.
| |