Linux-kselftest Archive on lore.kernel.org
 help / color / Atom feed
* arm64: bpf: Elide some moves to a0 after calls
@ 2020-01-28  2:11 Palmer Dabbelt
  2020-01-28  2:11 ` [PATCH 1/4] selftests/bpf: Elide a check for LLVM versions that can't compile it Palmer Dabbelt
                   ` (4 more replies)
  0 siblings, 5 replies; 11+ messages in thread
From: Palmer Dabbelt @ 2020-01-28  2:11 UTC (permalink / raw)
  To: Bjorn Topel
  Cc: daniel, ast, zlim.lnx, catalin.marinas, will, kafai,
	songliubraving, yhs, andriin, shuah, Palmer Dabbelt, netdev, bpf,
	linux-arm-kernel, linux-kernel, linux-kselftest,
	clang-built-linux, kernel-team

There's four patches here, but only one of them actually does anything.  The
first patch fixes a BPF selftests build failure on my machine and has already
been sent to the list separately.  The next three are just staged such that
there are some patches that avoid changing any functionality pulled out from
the whole point of those refactorings, with two cleanups and then the idea.

Maybe this is an odd thing to say in a cover letter, but I'm not actually sure
this patch set is a good idea.  The issue of extra moves after calls came up as
I was reviewing some unrelated performance optimizations to the RISC-V BPF JIT.
I figured I'd take a whack at performing the optimization in the context of the
arm64 port just to get a breath of fresh air, and I'm not convinced I like the
results.

That said, I think I would accept something like this for the RISC-V port
because we're already doing a multi-pass optimization for shrinking function
addresses so it's not as much extra complexity over there.  If we do that we
should probably start puling some of this code into the shared BPF compiler,
but we're also opening the doors to more complicated BPF JIT optimizations.
Given that the BPF JIT appears to have been designed explicitly to be
simple/fast as opposed to perform complex optimization, I'm not sure this is a
sane way to move forward.

I figured I'd send the patch set out as more of a question than anything else.
Specifically:

* How should I go about measuring the performance of these sort of
  optimizations?  I'd like to balance the time it takes to run the JIT with the
  time spent executing the program, but I don't have any feel for what real BPF
  programs look like or have any benchmark suite to run.  Is there something
  out there this should be benchmarked against?  (I'd also like to know that to
  run those benchmarks on the RISC-V port.)
* Is this the sort of thing that makes sense in a BPF JIT?  I guess I've just
  realized I turned "review this patch" into a way bigger rabbit hole than I
  really want to go down...

I worked on top of 5.4 for these, but trivially different versions of the
patches applied on Linus' master a few days ago when I tried.  LMK if those
aren't sane places to start from over here, I'm new to both arm64 and BPF so I
might be a bit lost.

[PATCH 1/4] selftests/bpf: Elide a check for LLVM versions that can't
[PATCH 2/4] arm64: bpf: Convert bpf2a64 to a function
[PATCH 3/4] arm64: bpf: Split the read and write halves of dst
[PATCH 4/4] arm64: bpf: Elide some moves to a0 after calls


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, back to index

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-28  2:11 arm64: bpf: Elide some moves to a0 after calls Palmer Dabbelt
2020-01-28  2:11 ` [PATCH 1/4] selftests/bpf: Elide a check for LLVM versions that can't compile it Palmer Dabbelt
2020-02-11 18:20   ` Nick Desaulniers
2020-01-28  2:11 ` [PATCH 2/4] arm64: bpf: Convert bpf2a64 to a function Palmer Dabbelt
2020-01-28  2:11 ` [PATCH 3/4] arm64: bpf: Split the read and write halves of dst Palmer Dabbelt
2020-01-28  2:11 ` [PATCH 4/4] arm64: bpf: Elide some moves to a0 after calls Palmer Dabbelt
2020-02-04 19:13   ` Björn Töpel
2020-02-11  0:15   ` Alexei Starovoitov
2020-02-04 19:30 ` Björn Töpel
2020-02-04 20:33   ` John Fastabend
2020-02-18 19:28     ` Palmer Dabbelt

Linux-kselftest Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-kselftest/0 linux-kselftest/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-kselftest linux-kselftest/ https://lore.kernel.org/linux-kselftest \
		linux-kselftest@vger.kernel.org
	public-inbox-index linux-kselftest

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kselftest


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git