On Thu, May 2, 2024 at 6:16 AM Puranjay Mohan <puranjay@xxxxxxxxxx> wrote: > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: > > > On Tue, Apr 30, 2024 at 10:59 AM Puranjay Mohan <puranjay@xxxxxxxxxx> wrote: > >> > >> Inline the calls to bpf_get_smp_processor_id() in the riscv bpf jit. > >> > >> RISCV saves the pointer to the CPU's task_struct in the TP (thread > >> pointer) register. This makes it trivial to get the CPU's processor id. > >> As thread_info is the first member of task_struct, we can read the > >> processor id from TP + offsetof(struct thread_info, cpu). > >> > >> RISCV64 JIT output for `call bpf_get_smp_processor_id` > >> ====================================================== > >> > >> Before After > >> -------- ------- > >> > >> auipc t1,0x848c ld a5,32(tp) > >> jalr 604(t1) > >> mv a5,a0 > >> > > > > Nice, great find! Would you be able to do similar inlining for x86-64 > > as well? Disassembling bpf_get_smp_processor_id for x86-64 shows this: > > > > Dump of assembler code for function bpf_get_smp_processor_id: > > 0xffffffff810f91a0 <+0>: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) > > 0xffffffff810f91a5 <+5>: 65 8b 05 60 79 f3 7e mov > > %gs:0x7ef37960(%rip),%eax # 0x30b0c <pcpu_hot+12> > > 0xffffffff810f91ac <+12>: 48 98 cltq > > 0xffffffff810f91ae <+14>: c3 ret > > End of assembler dump. > > We should be able to do the same in x86-64 BPF JIT. (it's actually how > > I started initially, I had a dedicated instruction reading per-cpu > > memory, but ended up with more general "calculate per-cpu address"). > > I feel in x86-64's case JIT can not do a (much) better job compared to the > current approach in the verifier. This direct memory read (using gs segment) ought to be a bit faster than calculating offset and then doing memory dereference, but yes, the difference won't be as big as you got with RISC-V and ARM64. Ok, never mind, we can always benchmark and add that later, no big deal. > > On RISC-V and ARM64, JIT was able to do it better because both of these > architectures save a pointer to the task struct in a special CPU > register. As x86-64 doesn't have enough extra registers, it uses a > percpu variable to store task struct, thread_info, and the cpu > number. > > P.S. - While doing this for BPF, I realized that ARM64 kernel code is > also not optimal as it is using the percpu variable and is not reading > the CPU register directly. So, I sent a patch[1] to fix it in the kernel > and get rid of the per-cpu variable in ARM64. > > > [1] https://lore.kernel.org/all/20240502123449.2690-2-puranjay@xxxxxxxxxx/ > > > Anyways, great work, a small nit below. > > > > Acked-by: Andrii Nakryiko <andrii@xxxxxxxxxx> > > Thanks, > Puranjay
