On Sun, Sep 29, 2024 at 10:33 PM Hari Bathini <hbathini@xxxxxxxxxxxxx> wrote: > > > > On 17/09/24 1:20 pm, Alexei Starovoitov wrote: > > On Sun, Sep 15, 2024 at 10:58 PM Hari Bathini <hbathini@xxxxxxxxxxxxx> wrote: > >> > >> + > >> + /* > >> + * Generated stack layout: > >> + * > >> + * func prev back chain [ back chain ] > >> + * [ ] > >> + * bpf prog redzone/tailcallcnt [ ... ] 64 bytes (64-bit powerpc) > >> + * [ ] -- > > ... > >> + > >> + /* Dummy frame size for proper unwind - includes 64-bytes red zone for 64-bit powerpc */ > >> + bpf_dummy_frame_size = STACK_FRAME_MIN_SIZE + 64; > > > > What is the goal of such a large "red zone" ? > > The kernel stack is a limited resource. > > Why reserve 64 bytes ? > > tail call cnt can probably be optional as well. > > Hi Alexei, thanks for reviewing. > FWIW, the redzone on ppc64 is 288 bytes. BPF JIT for ppc64 was using > a redzone of 80 bytes since tailcall support was introduced [1]. > It came down to 64 bytes thanks to [2]. The red zone is being used > to save NVRs and tail call count when a stack is not setup. I do > agree that we should look at optimizing it further. Do you think > the optimization should go as part of PPC64 trampoline enablement > being done here or should that be taken up as a separate item, maybe? The follow up is fine. It just odd to me that we currently have: [ unused red zone ] 208 bytes protected I simply don't understand why we need to waste this much stack space. Why can't it be zero today ? > [1] > https://lore.kernel.org/all/40b65ab2bb3a48837ab047a70887de3ccd70c56b.1474661927.git.naveen.n.rao@xxxxxxxxxxxxxxxxxx/ > [2] https://lore.kernel.org/all/20180503230824.3462-11-daniel@xxxxxxxxxxxxx/ > > Thanks > Hari
