From: Yonghong Song <yonghong.song@linux.dev>
To: Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
bpf <bpf@vger.kernel.org>
Subject: Re: Change default cpu version from v1 to v3 in llvm20
Date: Tue, 3 Sep 2024 07:50:12 -0700 [thread overview]
Message-ID: <c39622e0-a88c-4bb5-8ae4-83e138b3e2a2@linux.dev> (raw)
In-Reply-To: <fc2f30b5-c51b-3e2d-4282-2b22fb998285@iogearbox.net>
On 9/2/24 11:52 PM, Daniel Borkmann wrote:
> On 9/3/24 6:10 AM, Yonghong Song wrote:
>> Hi,
>>
>> Suggested by Alexei, I put a llvm20 diff to make cpu=v3 as the default
>> cpu version:
>> https://github.com/llvm/llvm-project/pull/107008
>>
>> cpu=v3 has been introduced in llvm9 (2019 H2) and the kernel cpu=v3
>> support should be available around the same time although I
>> cannot remember the exact kernel version.
>>
>> There are two motivation to move cpu version default from v1 to v3.
>>
>> First, to resolve correct usage of code like
>> (void)__sync_fetch_and_add(&ptr, value);
>> In cpu v1/v2, the above insn generates locked add insn, and
>> for cpu >= v3, the above insn generates atomic_fetch_add insn.
>> The atomic_fetch_add insn is the correct way for the eventual
>> insn for arm64. Otherwise, with locked add insn in arm64,
>> proper barrier will be missing and incorrect results may
>> be generated.
>>
>> Second, cpu=v3 should have better performance than cpu=v1
>> in most cases. In Meta, several years ago, we have conducted
>> performance evaluation to compare v1 and v3 for major bpf
>> programs running in our platform and we concluded v3 is
>> better than v1 in most cases and in other rare cases v1 and v3
>> have the same performance. So moving to v3 can help
>> performance too.
>>
>> If in rare cases, e.g. really old kernels, v1/v2 is the only
>> option, then users can set -mcpu=v1 explicitly.
>>
>> Please let us know if you still have some concerns in your
>> setup w.r.t. cpu v1->v3 transition.
>
> Sounds good to me! Is there a place somewhere in LLVM where this
> can be documented for the BPF backend (along with the various
> extensions), so that developers can find sth in the official LLVM
> docs if they search the web? I see that riscv and some other archs
> have documentation under [0] which seems to get deployed under [1].
Thanks Daniel.
Trying to have llvm doc for BPF backend has been discussed
before. IIRC, Fangrui Song suggested this when we tried to
add BPF reloc documents in Documentation/bpf/llvm_reloc.rst.
Eventually we added llvm_reloc.rst to kernel since this doc
is mostly interesting for kernel/bpf folks. We should add
an entry in bpf_devel_QA.rst to mention that default cpu
version change from v1 to v3.
Not sure whether we should have the same doc in
llvm.org/docs/. Let me discuss with other folks on this.
>
> [0] https://github.com/llvm/llvm-project/tree/main/llvm/docs
> [1] https://llvm.org/docs/RISCV/RISCVVectorExtension.html
>
> Thanks,
> Daniel
next prev parent reply other threads:[~2024-09-03 14:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-03 4:10 Change default cpu version from v1 to v3 in llvm20 Yonghong Song
2024-09-03 6:52 ` Daniel Borkmann
2024-09-03 14:50 ` Yonghong Song [this message]
2024-09-03 18:35 ` Daniel Borkmann
2024-09-03 23:06 ` Yonghong Song
2024-09-04 8:00 ` Jose E. Marchesi
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=c39622e0-a88c-4bb5-8ae4-83e138b3e2a2@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=martin.lau@linux.dev \
/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