Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759121AbcLSQZZ (ORCPT ); Mon, 19 Dec 2016 11:25:25 -0500 Received: from mx2.suse.de ([195.135.220.15]:48646 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754938AbcLSQZX (ORCPT ); Mon, 19 Dec 2016 11:25:23 -0500 Date: Mon, 19 Dec 2016 17:25:19 +0100 (CET) From: Miroslav Benes To: Josh Poimboeuf cc: Jessica Yu , Jiri Kosina , Petr Mladek , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Michael Ellerman , Heiko Carstens , x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, Vojtech Pavlik , Jiri Slaby , Chris J Arges , Andy Lutomirski , Ingo Molnar , Peter Zijlstra Subject: Re: [PATCH v3 01/15] stacktrace/x86: add function for detecting reliable stack traces In-Reply-To: <0315b36c08c104d56a4b43537fb300d200418996.1481220077.git.jpoimboe@redhat.com> Message-ID: References: <0315b36c08c104d56a4b43537fb300d200418996.1481220077.git.jpoimboe@redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1106 Lines: 28 On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 215612c..b4a6663 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -155,6 +155,7 @@ config X86 > select HAVE_PERF_REGS > select HAVE_PERF_USER_STACK_DUMP > select HAVE_REGS_AND_STACK_ACCESS_API > + select HAVE_RELIABLE_STACKTRACE if X86_64 && FRAME_POINTER && STACK_VALIDATION Tests to measure possible performance penalty of frame pointers were done by Mel Gorman. The outcome was quite clear. There IS a measurable impact. The percentage depends on the workflow but I think it is safe to say that FP usually takes 5-10 percents. If my understanding is correct there is no single culprit. Register pressure is definitely not a problem. We ran simple benchmarks while taking a register away from GCC (RBP or a common one). The impact is a combination of more cacheline pressure, more memory accesses and the fact that the kernel contains a lot of small functions. Thus, I think that DWARF should be the way to go here. Other than that the patch looks good to me. Miroslav