Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)
From: Josh Poimboeuf
Date: Thu Jul 13 2017 - 09:15:08 EST
On Wed, Jul 12, 2017 at 09:29:17PM -0700, Andi Kleen wrote:
> On Wed, Jul 12, 2017 at 05:47:59PM -0500, Josh Poimboeuf wrote:
> > On Wed, Jul 12, 2017 at 03:30:31PM -0700, Andi Kleen wrote:
> > > Josh Poimboeuf <jpoimboe@xxxxxxxxxx> writes:
> > > >
> > > > The ORC data format does have a few downsides compared to DWARF. The
> > > > ORC unwind tables take up ~1MB more memory than DWARF eh_frame tables.
> > > >
> > > Can we have an option to just use dwarf instead? For people
> > > who don't want to waste a MB+ to solve a problem that doesn't
> > > exist (as proven by many years of opensuse kernel experience)
> > >
> > > As far as I can tell this whole thing has only downsides compared
> > > to the dwarf unwinder that was earlier proposed. I don't see
> > > a single advantage.
> > Improved speed, reliability, maintainability. Are those not advantages?
> Ok. We'll see how it works out.
> The memory overhead is quite bad though. You're basically undoing many
> years of efforts to shrink kernel text. I hope this can be still
> done better.
If we're talking *text*, this further shrinks text size by 3% because
frame pointers can be disabled.
As far as the data size goes, is anyone *truly* impacted by that extra
1MB or so? If you're enabling a DWARF/ORC unwinder, you're already
signing up for a few extra megs anyway.
I do have a vague idea about how to reduce the data size, if/when the
size becomes a problem. Basically there's a *lot* of duplication in the
$ tools/objtool/objtool orc dump vmlinux | wc -l
$ tools/objtool/objtool orc dump vmlinux |cut -d' ' -f2- |sort |uniq |wc -l
So that's over 300,000 6-byte entries, only 345 of which are unique.
There should be a way to compress that. However, it will probably
require sacrificing some combination of speed and simplicity.