Hi Chris, On Tue, Jul 7, 2015 at 9:47 PM, Chris Zankel <ch...@zankel.net> wrote: > Not such a big fan about these changes as they introduce additional > load and stores and a branch. > > Copy spill area: > - is this only for debugging? Could the debugger identify the 'kernel > exception' frame and handle it appropriately?
For the debugger and all in-kernel stack tracers: perf, ftrace, oprofile. I'm not sure how the kernel exception frame can be identified, especially for the nested kernel re-entries. > - if we need it for debugging/perf, maybe move these line under a > kernel option (could be enabled by default) Ok. > - since we know the kernel stack frame size, why can't we just load > from that offset (instead of the l32i and add). Also, can't we use > s32e (need to look up the spec again). Oh, right, l32e and s32e make perfect sense here, I thought about it, but somehow I was under impression we could get here from userspace and CRING would be wrong for the kernel stack. We obviously can't. > Branch: > - is there any logical change in the code or are these only to avoid using a0? Yes. > - if for a0, couldn't we load a0 just before the 'xsr a3, ps' and keep > the code as before? Sure. -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/