On Thu, 23 Jun 2016, Jiri Kosina wrote: > > I haven't looked at the fentry solution, but the code I'm involved in saves > > the registers so that ftrace, live patch and friends can work freely. But > > then it restores all regs and _then_ calls the replacement, so ftrace > > saving all regs is no gain at all. > > You're right, thanks for bringing this up. > > In principle we should be able to modify the trampoline so that it > performs its own register saving (in ftrace_regs_caller) and restoring > (*), completely shielding the new function from any optimization gcc might > have done on registers, shouldn't we? > > (*) we'll have to piggy-back on ftrace_epilogue on that, i.e. making the > return to the original code go through trampoline as well (the same > way graph tracer works) Okay, after looking more about how ftrace implements the return trampolines for graph caller, it'd be rather difficult to implement in a way that we neither interfere with ftrace graph tracer (the ftrace_ret_stack in task_struct) nor introduce a serious performance overhead or stack usage pressure. I am pretty sure the overhead we'd be adding would be much worse than just really simply turning the IPA-RA off in CONFIG_LIVEPATCH-enabled kernels is the easiest way to go. After talking to Jan Hubicka, I'd actually suggest turning off most/all the IPA optimizations; they are supposed to be of questionable benefit for kernel anyway, and they might be causing serious issues for us. I am planning to ask our performance team to measure the impact this'd have. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
