From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 168D0126BFE for ; Tue, 3 Sep 2024 23:06:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725404785; cv=none; b=f82uixyuwcnNlxlSIwHaJD0RgAtdM6mulaoGNXzpl5Yw69c/8Z/Z5Zv0fnb29YgrzlHFIcWuhbqpbEWzRkmTXY7GkSNYsdye3aY/W0HwO1Dv+GWASLW6qnUA2r0O1DYBYkwPVXdS6shGt1zq/PuuXaIB2CMq0w/WRRtotrX8VQ0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725404785; c=relaxed/simple; bh=sR3YDwfr1yz5m0dk9IZrHpJQ8yeSIDRvzhDM/NkGIxY=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=tx3YSW9f2nqmJo/SYNdTxaA2QP2AjIeqFbzLlnjyAhJc/gLS6ogY6/QEoQXCcHb+1HseKNPF2hAjlssFKpcQydylgZp3IeqSCMQblc6ZozlIMvjaLwAc6XGzqfR5ZnSeRgx/jaVR2yxQDlVf6MZ0gcdckgaQwcVqmaYJqTLGnnQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=RRWkizCs; arc=none smtp.client-ip=95.215.58.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="RRWkizCs" Message-ID: <504ced9b-b938-4cca-b108-28775404faa4@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1725404779; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sR3YDwfr1yz5m0dk9IZrHpJQ8yeSIDRvzhDM/NkGIxY=; b=RRWkizCsJYS/fZQxby2NJ35uHxjdS8+kzYR2Rtr+cQoVX884Lb+9SuUEhFJSz607Hp+o8W pDHfuHViRJY2pOa15A/86ZXY9lE1FULhmNgiy8+KsjsWyjWca0ouUW86xBdgOs+m/s9r3D NxsumhDnQSjgtr67fFhpkGKQS7X6I0I= Date: Tue, 3 Sep 2024 16:06:12 -0700 Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: Change default cpu version from v1 to v3 in llvm20 To: Daniel Borkmann , Alexei Starovoitov , Andrii Nakryiko , Martin KaFai Lau , bpf References: <90a00496-bcf9-358c-3b9e-e7a861728733@iogearbox.net> Content-Language: en-GB X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yonghong Song In-Reply-To: <90a00496-bcf9-358c-3b9e-e7a861728733@iogearbox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 9/3/24 11:35 AM, Daniel Borkmann wrote: > On 9/3/24 4:50 PM, Yonghong Song wrote: >> 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. > > I was mostly thinking that not everyone might be looking into > kernel docs (say, eBPF for Windows folks using LLVM), and at > least on gcc docs/wiki you'll find information & quirks about > gcc-bpf backend [2]. > >   [2] https://gcc.gnu.org/wiki/BPFBackEnd Thanks, Daniel. Eduard and I will look into this. Yonghong > >>>   [0] https://github.com/llvm/llvm-project/tree/main/llvm/docs >>>   [1] https://llvm.org/docs/RISCV/RISCVVectorExtension.html >>> >>> Thanks, >>> Daniel >