Re: [PATCH 1/1] x86: fix text_poke


* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

I'd much rather see something truly generic that doesn't need any
pre-inserted "markers" at all that disable optimizations, and that
allows just about anything. Including live system bug-fixes etc
(imagine finding a bug - and not at somethign that was previously
already "marked" - and just replacing the buggy function with a
non-buggy one).

Ob'plug: with the pending dyn-ftrace function tracer feature we do
something rather close to that already: we have a 5 byte NOP in the
prologue of every function that can be used as a non-destructive 'branch
away' place.

Right now we use that to trace a (regex-ish pattern identified) set of
functions. The regex pattern can be configured runtime via
/debug/tracing/function_filter is not parsed runtime in any fastpath -
it is used to activate/deactivate the tracepoints and patches them from
NOPs into CALLs.

_But_ the same mechanism could perhaps be used to patch the function as
well.

The cost is +5 bytes of NOP for every function in the system, but in
practice we've not been able to measure any actual runtime costs of
these NOPs - neither in micro-benchmarks nor in macro-benchmarks. (the
only real cost here is the +5 bytes of I$ cost - otherwise the NOP will
just be skipped by the decoder.)

the patching of these NOPs is inherently safe because they are inserted
at build time. There's no negative impact to gcc optimizations at all.
We get a nice selection of 75,000 tracepoints in an allmodconfig kernel
- without _any_ source code level impact in the functions.

On the other hand, i'm not opposed to a handful of static markers either
- i think the best model is to have both of these facilities. There are
a couple of 'core events' that are not expressed via function calls, and
even where they are expressed via function calls the function call
layout is not stable while markers are stable across kernel versions.
The notion of "a context-switch happened from task X to task Y" or "task
X woke up task Y" is not going to change anytime soon so i'm not opposed
to exposing that kind of information. And once we accept the static
markers, we might as well make them as cheap as possible.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [patch for 2.6.26 0/7] Architecture Independent Markers
    ... as far as the assembly for the markers in the fast path is ... cache footprint of the kernel quite substantially, ... slowpath cost. ... I like your tracing filters interface. ...
    (Linux-Kernel)
  • Re: After a hard weeks work.
    ... but something like pigs does not seem to fit. ... out-group markers are arbitrary and costly. ... so some markers can be relatively cost free. ...
    (talk.origins)
  • Re: After a hard weeks work.
    ... I think those laws are clearly, ... but something like pigs does not seem to fit. ... out-group markers are arbitrary and costly. ... so some markers can be relatively cost free. ...
    (talk.origins)
  • Re: [Clax86list] Re: instruction rescheduler?
    ... that this is the "lowest cost NOP possible", it is not a zero cost NOP. ... So the remaining costs are instruciton decode cost and instruction execution cost. ... Anyways, then Pentium4 decided to do it differently and I forget the decode, other than it's different and hence slows down Pentium III optimized code. ...
    (comp.lang.asm.x86)
  • Re: [PATCH] simple dprobe like markers for the kernel
    ... practically zero optimisation cost. ... IMHO, as Aoki investigated, the overhead of markers is not so big ... while kprobes takes hundreds of nano-seconds. ... thousands of markers in kernel or drivers. ...
    (Linux-Kernel)