Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933877AbdGLI1S (ORCPT ); Wed, 12 Jul 2017 04:27:18 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:34835 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933243AbdGLI1P (ORCPT ); Wed, 12 Jul 2017 04:27:15 -0400 Date: Wed, 12 Jul 2017 10:27:10 +0200 From: Ingo Molnar To: Josh Poimboeuf Cc: x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Linus Torvalds , Andy Lutomirski , Jiri Slaby , "H. Peter Anvin" , Peter Zijlstra , Mike Galbraith Subject: Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf) Message-ID: <20170712082710.g2syanmhtwqeus4o@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2619 Lines: 67 * Josh Poimboeuf wrote: > The biggest change is that undwarf was renamed to ORC. Here's the > relevant explanation from the docs: > > Etymology > --------- > > Orcs, fearsome creatures of medieval folklore, are the Dwarves' natural > enemies. Similarly, the ORC unwinder was created in opposition to the > complexity and slowness of DWARF. > > "Although Orcs rarely consider multiple solutions to a problem, they do > excel at getting things done because they are creatures of action, not > thought." [3] Similarly, unlike the esoteric DWARF unwinder, the > veracious ORC unwinder wastes no time or siloconic effort decoding > variable-length zero-extended unsigned-integer byte-coded > state-machine-based debug information entries. > > Similar to how Orcs frequently unravel the well-intentioned plans of > their adversaries, the ORC unwinder frequently unravels stacks with > brutal, unyielding efficiency. > > ORC stands for Oops Rewind Capability. Perfect naming! (ORC might also stand for "Optimized Rewind Capability".) > Create a new "ORC" unwinder, enabled by CONFIG_ORC_UNWINDER, and plug it > into the x86 unwinder framework. Objtool is used to generate the ORC > debuginfo. The ORC debuginfo format is basically a simplified version > of DWARF CFI. More details below. BTW., we should perhaps consolidate our unwinder related Kconfig space, hierarchically: CONFIG_UNWINDER CONFIG_UNWINDER_ORC CONFIG_UNWINDER_FRAME_POINTERS Note that as a side effect it would be a valid small systems build option to have no unwinder at all, if CONFIG_EXPERT=y is set and such: !CONFIG_UNWINDER=n would be a sibling to !CONFIG_BUG. CONFIG_FRAME_POINTERS et al would be left for architectures where it has a meaning beyond backtrace generation. (Not sure whether there's any such architectures.) > The unwinder works well in my testing. It unwinds through interrupts, > exceptions, and preemption, with and without frame pointers, across > aligned stacks and dynamically allocated stacks. If something goes > wrong during an oops, it successfully falls back to printing the '?' > entries just like the frame pointer unwinder. Ok, I'll start applying your patches after -rc1, unless anyone objects. > 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. Could we also write this in percentage, not absolute RAM size - i.e. ORC unwind tables take 30% more RAM (+0.7 MB on an x86 defconfig kernel) than DWARF eh_frame tables. Thanks, Ingo