Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753474AbZFWR0S (ORCPT ); Tue, 23 Jun 2009 13:26:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752620AbZFWR0H (ORCPT ); Tue, 23 Jun 2009 13:26:07 -0400 Received: from mx2.redhat.com ([66.187.237.31]:48492 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752363AbZFWR0F (ORCPT ); Tue, 23 Jun 2009 13:26:05 -0400 Message-ID: <4A4110A3.2060808@redhat.com> Date: Tue, 23 Jun 2009 13:28:03 -0400 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Andi Kleen CC: Ingo Molnar , Ananth N Mavinakayanahalli , lkml , "H. Peter Anvin" , Frederic Weisbecker , Jim Keniston , Srikar Dronamraju , Christoph Hellwig , Steven Rostedt , Anders Kaseorg , Tim Abbott , systemtap , DLE Subject: Re: [RFC][ PATCH -tip v2 0/7] kprobes: Kprobes jump optimization support References: <20090622212255.5384.53732.stgit@localhost.localdomain> <87vdmn179n.fsf@basil.nowhere.org> <4A40DDAD.6020202@redhat.com> <87bpoe29jo.fsf@basil.nowhere.org> In-Reply-To: <87bpoe29jo.fsf@basil.nowhere.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2910 Lines: 70 Andi Kleen wrote: > Masami Hiramatsu writes: > >> Hi Andi, >> >> Andi Kleen wrote: >>> Masami Hiramatsu writes: >>>> The gcc's crossjumping unifies equivalent code by inserting indirect >>>> jumps which jump into other function body. It is hard to know to where >>>> these jumps jump, so I decided to disable it when setting >>>> CONFIG_OPTPROBES=y. >>> That sounds quite bad. Tail call optimization is an important optimization >>> that especially on kernel style code (lots of indirect pointers >>> and sometimes deep call chains) is very useful. It would be quite >>> sad if production kernels would lose that optimization. >> I think the crossjumping is not the tail call optimization, >> http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gccint/Passes.html > > Statement didn't make sense then. The RTL crossjump pass you're referring > AFAIK does not jump into other functions, it only optimizes jumps > inside a function (unless you're talking about inlines) If so, that's a good news for me. Then just drop the disable crossjumping patch is enough. >>> Also tail calls in C should always jump directly to another function, >>> so they shouldn't be particularly complex to manage. >> Tail call jumps directly into the head of another function, >> not the middle. Thus it is safe. > > cross jumping does neither. > >>>> I also decided not to optimize probes when it is in functions which >>>> will cause exceptions, because the exception in the kernel will jump >>>> to a fixup code and the fixup code jumps back to the middle of the >>>> same function body. >>> Note that not only exceptions do that, there are a few other cases >>> where jumps in and out of out of line sections happen. You might >>> need a more general mechanism to detect this. >> As far as I can see (under arch/x86), Almost all fixup entries are >> defined with ex_table entries, and others jump to the head of >> symbols(or functions). The jumps which jump into the middle of >> some functions are what I need to find, and, as far as I know, >> those fixup jumps are used with exception tables. Of course, >> I might miss some fixup codes, in that case, please let me know:-) > > One case for example are out of line sections generated by gcc itself > with the right options. Hmm, would you know what is the actual name of that section and option? I think another possible solution is decoding those sections and black-listing the target functions when making vmlinux or loading modules. Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division e-mail: mhiramat@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/