lkml.org 
[lkml]   [2008]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/1] x86: fix text_poke
    Jeremy Fitzhardinge wrote:
    > Ingo Molnar wrote:
    >> And once we accept the static markers, we might as well make them as
    >> cheap as possible.
    >
    > Sure, so long as you take "as cheap as possible" to mean cheap in both
    > implementation complexity as well as runtime cost.
    >
    > I don't have any specific objections to any of the stuff that Mathieu is
    > working on, but it does worry me that each time a problem is addressed
    > it ends up being an even more subtle piece of code. I just haven't seen
    > enough concrete justification to make me feel comfortable with it all.
    >
    > It seems to me that a relatively simple implementation which allows the
    > desired tracing/marking functionality is the first step. If that proves
    > to cause a significant performance deficit then enabled then we can work
    > out how to address it in due course. But doing it all at once before
    > merging anything seems like overkill, particularly when we're talking
    > about specifics of gcc's codegen patterns, disassembling code fragments,
    > etc.
    >

    I really feel that the latest information that has come up has indicated
    that things are really not what they should be. They are in line, have
    a substantial probe cost, and we're messing around with how to jump
    around them.

    That's not the problem.

    I maintain what I said before: a call instruction (which defaults to a
    NOP), and then extract the state based on debugging info or assembler
    annotations.

    As far as patchable static jumps, I can see the utility of them, but I
    don't think this project is one of them. However, I believe the right
    way to do them is via compiler support.

    -hpa


    \
     
     \ /
      Last update: 2008-04-28 23:09    [W:4.221 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site