From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6371 invoked by alias); 23 Jun 2009 17:26:41 -0000 Received: (qmail 6360 invoked by uid 22791); 23 Jun 2009 17:26:40 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_72,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Jun 2009 17:26:32 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n5NHPSKZ003151 for ; Tue, 23 Jun 2009 13:26:29 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5NHPSSe023344 for ; Tue, 23 Jun 2009 13:25:28 -0400 Received: from [10.16.2.46] (dhcp-100-2-46.bos.redhat.com [10.16.2.46]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5NHPQYN027678; Tue, 23 Jun 2009 13:25:27 -0400 Message-ID: <4A4110A3.2060808@redhat.com> Date: Tue, 23 Jun 2009 17:26:00 -0000 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> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q2/txt/msg01017.txt.bz2 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