From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755963AbYEDQe4 (ORCPT ); Sun, 4 May 2008 12:34:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753333AbYEDQer (ORCPT ); Sun, 4 May 2008 12:34:47 -0400 Received: from terminus.zytor.com ([198.137.202.10]:51298 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752225AbYEDQeq (ORCPT ); Sun, 4 May 2008 12:34:46 -0400 Message-ID: <481DE1D2.4080704@zytor.com> Date: Sun, 04 May 2008 09:18:26 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Mathieu Desnoyers CC: Jeremy Fitzhardinge , Linus Torvalds , Andi Kleen , Ingo Molnar , Jiri Slaby , David Miller , zdenek.kabelac@gmail.com, rjw@sisk.pl, paulmck@linux.vnet.ibm.com, akpm@linux-foundation.org, linux-ext4@vger.kernel.org, herbert@gondor.apana.org.au, penberg@cs.helsinki.fi, clameter@sgi.com, linux-kernel@vger.kernel.org, pageexec@freemail.hu Subject: Re: [PATCH 1/1] x86: fix text_poke References: <481241DC.3070601@zytor.com> <20080425211205.GC25950@Krystal> <481249FB.8070204@zytor.com> <20080425214704.GD25950@Krystal> <48125635.3060303@zytor.com> <20080425223015.GB31226@Krystal> <20080428204342.GD27154@Krystal> <48163B50.8010608@goop.org> <20080504150353.GB23137@Krystal> In-Reply-To: <20080504150353.GB23137@Krystal> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mathieu Desnoyers wrote: > > I am not saying that the standard marker will have to inhibit > optimizations. Actually, it's the contrary : a well-thought marker > should _not_ modify that kind of optimization, and we should put markers > in code locations less likely to inhibit gcc optimizations. However, in > the case where we happen to be interested in information otherwise > optimized away by GCC, it makes sense to inhibit this optimization in > order to have the information available for tracing. > > I expect this to happen rarely, but I think we must deal with > optimizations to make sure we never trace garbage due to some unexpected > gcc optimization. I think it's a small (e.g. undetectable at the > macrobenchmark level) price to pay to get correct tracing information. > That's a pretty flippant reply... liveness causes register pressure which can cause rapid degradation in code quality on a register-starved architecture like x86. -hpa