Skip to content

Conversation

@kernel-patches-daemon-bpf-rc
Copy link

Pull request for series with
subject: bpf,x86: do RSB balance for trampoline
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1019376

@kernel-patches-daemon-bpf-rc
Copy link
Author

Upstream branch: 11369e6
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1019376
version: 1

@kernel-patches-daemon-bpf-rc
Copy link
Author

Upstream branch: efa4756
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1019376
version: 1

@kernel-patches-daemon-bpf-rc
Copy link
Author

Upstream branch: b3387b3
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1019376
version: 1

@kernel-patches-daemon-bpf-rc
Copy link
Author

Upstream branch: 4cb4897
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1019376
version: 1

In origin call case, we skip the "rip" directly before we return, which
break the RSB, as we have twice "call", but only once "ret".

Do the RSB balance by pseudo a "ret". Instead of skipping the "rip", we
modify it to the address of a "ret" insn that we generate.

The performance of "fexit" increases from 76M/s to 84M/s. Before this
optimize, the bench resulting of fexit is:

fexit          :   76.494 ± 0.216M/s
fexit          :   76.319 ± 0.097M/s
fexit          :   70.680 ± 0.060M/s
fexit          :   75.509 ± 0.039M/s
fexit          :   76.392 ± 0.049M/s

After this optimize:

fexit          :   86.023 ± 0.518M/s
fexit          :   83.388 ± 0.021M/s
fexit          :   85.146 ± 0.058M/s
fexit          :   85.646 ± 0.136M/s
fexit          :   84.040 ± 0.045M/s

Things become a little more complex, not sure if the benefits worth it :/

Signed-off-by: Menglong Dong <[email protected]>
@kernel-patches-daemon-bpf-rc
Copy link
Author

At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=1019376 expired. Closing PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants