Ping? I haven't heard anything on this. Thanks,
-corey On 09/18/2014 07:58 AM, Corey Minyard wrote: > On 09/18/2014 04:58 AM, Ralf Baechle wrote: >> On Tue, Sep 16, 2014 at 04:45:25PM -0500, [email protected] wrote: >> >>> From: Corey Minyard <[email protected]> >>> >>> The MIPS frame save code was just saving a few registers, enough to >>> do a backtrace if every function set up a frame. However, this is >>> not working if you are using DWARF unwinding, because most of the >>> registers are wrong. This was causing kdump backtraces to be short >>> or bogus. >>> >>> So save all the registers. >> The stratey of partial and full stack frames was developed in '97 to bring >> down the syscall overhead. It certaily was very effective - it brought >> down the syscall latency to the level of Alphas running at much higher >> clock. >> >> That certainly worked well back then for kernel 2.0 / 2.2. But the syscall >> code has become much more complex. Since then support for 64 bit kernels, >> two 32 bit ABIs running on a 64 bit kernels and numerous features that >> changed the once simple syscall path have been implemented. My gut feeling >> is it might be worth to yank out the whole optimization to see how much >> code complexity we get rid of in exchange for how much extra syscall >> latency. > I"m not sure I understand. From what I can tell, this code is only > called by > things that print stack traces, kdb, and kexec/kdump. So it shouldn't be in > any normal syscall path. > > This patch will currently only help kdump, but it will be necessary if > anyone > adds MIPS support for DWARF unwinding for stack traces. And you'd have > to fix some things in context switching, too, I think. > > From what I can tell the partial save for syscalls is a good idea. You > don't have > to save half the registers and it doesn't affect tracebacks, kdump, or > anything else > like that. > > -corey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
