From owner-freebsd-arch@FreeBSD.ORG Thu Dec 27 04:41:56 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B5F5A18; Thu, 27 Dec 2012 04:41:56 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 593408FC08; Thu, 27 Dec 2012 04:41:56 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id BCC8C1A3C1A; Wed, 26 Dec 2012 20:41:55 -0800 (PST) Message-ID: <50DBD193.7080505@mu.org> Date: Wed, 26 Dec 2012 20:41:55 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Peter Wemm Subject: Re: UPDATE Re: making use of userland dtrace on FreeBSD References: <50D49DFF.3060803@ixsystems.com> <50DBC7E2.1070505@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , Adrian Chadd , Rui Paulo , Alfred Perlstein X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 04:41:56 -0000 On 12/26/12 8:21 PM, Peter Wemm wrote: > On Wed, Dec 26, 2012 at 8:00 PM, Alfred Perlstein wrote: > >> What would be the drawbacks? I don't want to hurt freebsd for heavy >> performance, but I think this functionality should work out of the box for >> most people. > The drawbacks are mostly performance related. It defeats a certain > hardware optimizations for call/return on leaf functions. It'll > mostly affect things like math, crypto, compression and multimedia > libraries (that's ffmpeg, bzip2/gzip/libarchive, openssl, etc) but, we > generally don't seem to care about that sort of performance anyway, so > what's one more loss? Can you clarify some? If it was somewhat easy to re-add -fomit-frame-pointer to critical libraries like this, then that would be OK? To be honest, I'm not sure if you're serious about "generally don't seem to care" or just feel defeated on the issue and we should care. What do you think? > > Of course it wouldn't be required with dwarf unwinding awareness, but > we don't have that. > > We have -fno-omit-frame-pointer on the amd64 kernel whenever debugging > is compiled in because there's no unwinder for doing stack traces. We > need a dwarf2+ unwinder and somebody to instrument the call frame > state through the remaining assembler code. > How much work is that exactly? I've only been a gdb user, not a hacker. What is the right call here? Is the increased functionality worth the performance hit until we get the dwarf2+ unwinder? Or not worth it until we get the unwinder? There's no numbers, but does anyone care to provide some, or give me some things to test to bring numbers back? -Alfred