On Thu, Jun 29, 2017 at 09:55:47AM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > Undwarf vs frame pointers > > ------------------------- > > > > With frame pointers enabled, GCC adds instrumentation code to every > > function in the kernel. The kernel's .text size increases by about > > 3.2%, resulting in a broad kernel-wide slowdown. Measurements by Mel > > Gorman [1] have shown a slowdown of 5-10% for some workloads. > > > > In contrast, the undwarf unwinder has no effect on text size or runtime > > performance, because the debuginfo is out of band. So if you disable > > frame pointers and enable undwarf, you get a nice performance > > improvement across the board, and still have reliable stack traces. > > > > Another benefit of undwarf compared to frame pointers is that it can > > reliably unwind across interrupts and exceptions. Frame pointer based > > unwinds can skip the caller of the interrupted function if it was a leaf > > function or if the interrupt hit before the frame pointer was saved. > > > > The main disadvantage of undwarf compared to frame pointers is that it > > needs more memory to store the undwarf table: roughly 3-5MB depending on > > the kernel config. > > Note that it's not just a performance improvement, but also an instruction cache > locality improvement: 3.2% .text savings almost directly transform into a > similarly sized reduction in cache footprint. That can transform to even higher > speedups for workloads whose cache locality is borderline. I'll add that detail to the docs. > I _really_ like this feature, and the independence of the debuginfo data format. > > Logistically it's too bad we are 3 days away from the merge window to be able to > pick this up: > > > 56 files changed, 3466 insertions(+), 1765 deletions(-) > > OTOH most of the diffstat is in objtool. > > Any objections to applying the first 3 objtool patches straight away and see > whether anything breaks? That would significantly reduce the size of the rest of > the patch set. Merging the first 3 patches now sounds good to me. They implement "stack validation 2.0" which is a good standalone improvement even without undwarf. I think I've already ironed out all the issues reported by the build bot. > > I'm not tied to the 'undwarf' name, other naming ideas are welcome. > > Ha, a new bike shed painting job! ;-) > > I think 'undwarf' isn't a bad name, it's short, catchy and describes the purpose > of the effort. > > But I cannot resist some other suggestions, after 'elf' and 'dwarf' the obvious > candidates from the peoples of Middle-earth would be: > > - 'Hobbit' > - 'Eagle' > - 'Ent' > - 'Dragon' > - 'Troll' > - 'Ainur' > > 'struct troll_entry' has a certain charm to it. > > 'Eagle' is even nicer IMHO: larger than a dwarf but so much faster - and eagles > are beautiful! Plus the name is 2 letters shorter than 'unwdwarf', win-win. Finally, we get to the important part ;-) Thus far I've been partial to undwarf, and I haven't been able to shake it. But I like some of your suggestions. Especially troll and hobbit. Will need to do some more deep thinking about it :-) -- Josh -- 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
