[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170713042916.GD3044@two.firstfloor.org>
Date: Wed, 12 Jul 2017 21:29:17 -0700
From: Andi Kleen <andi@...stfloor.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Lutomirski <luto@...nel.org>, Jiri Slaby <jslaby@...e.cz>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Mike Galbraith <efault@....de>
Subject: Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)
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@...hat.com> 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.
-Andi
Powered by blists - more mailing lists