From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756267AbYDZGu1 (ORCPT ); Sat, 26 Apr 2008 02:50:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752053AbYDZGuO (ORCPT ); Sat, 26 Apr 2008 02:50:14 -0400 Received: from gw.goop.org ([64.81.55.164]:46999 "EHLO mail.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751990AbYDZGuN (ORCPT ); Sat, 26 Apr 2008 02:50:13 -0400 Message-ID: <4812D09D.6010901@goop.org> Date: Fri, 25 Apr 2008 23:50:05 -0700 From: Jeremy Fitzhardinge User-Agent: Thunderbird 2.0.0.12 (X11/20080418) MIME-Version: 1.0 To: Mathieu Desnoyers CC: Linus Torvalds , "H. Peter Anvin" , 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: <20080425161916.GD3265@one.firstfloor.org> <20080425163035.GE9503@Krystal> <481209F2.4050908@zytor.com> <20080425170929.GA16180@Krystal> <20080425183748.GB16180@Krystal> <48123C9B.9020306@zytor.com> <20080425203717.GB25950@Krystal> <481241DC.3070601@zytor.com> <20080425211205.GC25950@Krystal> In-Reply-To: <20080425211205.GC25950@Krystal> X-Enigmail-Version: 0.95.6 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: > * Linus Torvalds (torvalds@linux-foundation.org) wrote: > >> On Fri, 25 Apr 2008, H. Peter Anvin wrote: >> >>> Yes, that should work. It's still ugly, and I have to say I find the >>> complexity rather distasteful. I am willing to be convinced it's worth it, >>> but I would really like to see hard numbers. >>> >> I really cannot imagine that this kind of pain is *ever* worth it. >> >> Please give an example of something so important that we'd want to do >> complex code rewriting on the fly. What _is_ the point of imv_cond()? >> >> Linus >> > > The point is to provide a way to dynamically enable code at runtime > without noticeable performance impact on the system. It's principally > useful to control the markers in the kernel, which can be placed in very > frequently executed code paths. The original markers add a memory read, > test and conditional branch at each marker site. By using the immediate > values patchset, it goes down to a load immediate value, test and branch. > > However, Ingo was still unhappy with the conditional branch, so I cooked > this jump patching optimization on top of the immediate values. I think all this demonstrates that the conditional branch is a bearable cost compared to the alternative. A conditional branch which almost always branches the same way is very predictable, and really shouldn't cost very much. J