Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752898AbdGLWyG (ORCPT ); Wed, 12 Jul 2017 18:54:06 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:43857 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752321AbdGLWyF (ORCPT ); Wed, 12 Jul 2017 18:54:05 -0400 X-ME-Sender: X-Sasl-enc: eakofEQpAc95mIPtCPcD8Bp+n2gWAY/SZdyv12YoQwc8 1499900044 Date: Wed, 12 Jul 2017 15:54:02 -0700 From: Andres Freund To: Josh Poimboeuf Cc: x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Linus Torvalds , Andy Lutomirski , Jiri Slaby , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Mike Galbraith Subject: Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf) Message-ID: <20170712225402.q45uhl4s6hpzajgg@alap3.anarazel.de> References: <20170712214920.5droainfqjmq7sgu@alap3.anarazel.de> <20170712223225.zkq7tdb7pzgb3wy7@treble> <20170712223605.fplf4mvvs66rspxh@alap3.anarazel.de> <20170712224045.4bsa6vngowr72kzk@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170712224045.4bsa6vngowr72kzk@treble> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1103 Lines: 28 On 2017-07-12 17:40:45 -0500, Josh Poimboeuf wrote: > On Wed, Jul 12, 2017 at 03:36:05PM -0700, Andres Freund wrote: > > Hi, > > > > On 2017-07-12 17:32:25 -0500, Josh Poimboeuf wrote: > > > If you want perf to be able to use ORC instead of DWARF for user space > > > binaries, that's not currently possible, though I don't see any > > > technical blockers for doing so. Perf would need to be taught to read > > > ORC data. > > > > Right, that's what I was hoping for. > > > > > > > And I think it should be possible to convert DWARF to ORC, assuming the > > > DWARF data is trusted. We could probably add an objtool subcommand for > > > that. > > > > That'd be pretty helpful. > > Can I ask why? Is DWARF too slow, or is it something else? Both. Dwarf is really slow and uses a lot of space - on a bigger machine it's often nearly unusable. Secondly dwarf isn't available for BPF based stuff, IIUC because the kernel has to create a full backtrace there (rather than saving enough data that userland can do so). Which wasn't "allowed" to be done in-kernel w/ dwarf, just fp so far. - Andres