On Wednesday, July 16, 2025 12:35 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> write: > On Tue, Jul 15, 2025 at 1:37 AM Menglong Dong <menglong.dong@xxxxxxxxx> wrote: > > > > > > On 7/15/25 10:25, Alexei Starovoitov wrote: [......] > > > > According to my benchmark, it has ~5% overhead to save/restore > > *5* variants when compared with *0* variant. The save/restore of regs > > is fast, but it still need 12 insn, which can produce ~6% overhead. > > I think it's an ok trade off, because with one global trampoline > we do not need to call rhashtable lookup before entering bpf prog. > bpf prog will do it on demand if/when it needs to access arguments. > This will compensate for a bit of lost performance due to extra save/restore. I don't understand here :/ The rhashtable lookup is done at the beginning of the global trampoline, which is called before we enter bpf prog. The bpf progs is stored in the kfunc_md, and we need get them from the hash table. If this is the only change, it is still OK. But according to my previous, the rhashtable can cause ~7% addition overhead. So if we change both them, the performance of tracing-multi is a little far from tracing, which means ~25% performance gap for the functions that have no arguments. About the rhashtable part, I'll do more research on it and feedback late. > > PS > pls don't add your chinatelecom.cn email in cc. > gmail just cannot deliver there and it's annoying to keep deleting > it manually in every reply. Sorry about that. I filtered out such message in my gmail, and didn't notice it. I'll remove it from the CC in the feature :) Thanks! Menglong Dong
Attachment:
signature.asc
Description: This is a digitally signed message part.
