Re: [patch 0/2] Immediate Values - jump patching update

Hi!

At least one complication though is that in the case of markers,
tracing parameter evaluation is itself conditional (and placed out of
the hot path due to -freorder-blocks). With your suggested kind of
assembly ("g" constraints for all the expressions), those expressions
would be evaluated unconditionally, just to make them live somewhere.
That unconditional evaluation can easily entail memory reads and
dependent arithmetic, which could swamp the savings of eliminating
the marker-style conditional branch.

Well, it depends a bit on what kind of expressions you put in there.
You don't really want to put *expressions* in there as much as you
want to put *data* references in there, although, of course, if your
have something like "foo->bar[baz]->quux" then it's easy to trip upon.

and that's exactly what was tripped upon in sched.o and analyzed.

Furthermore, the suggestion of doing this exclusively within the DWARF2
space - besides the not particularly minor complication of it not being
implemented yet - is:

- quite substantially complex on its own

- would make Linux instrumentation dependent on all sorts of DWARF2
details which we had our 'fun' with before. (I proffer that that's
more fragile than any code patching can ever be.)

- if done self-sufficiently (i.e. if a kernel image can be used to
trace things, which i believe any usable kernel tracer must offer),
it would, with the current debug info format, enlargen the kernel RAM
image with quite a substantial amount of unswappable kernel memory.

I am not sure self-sufficiency is good goal here.

If tracing becomes part of kernel-user ABI, we are in big trouble...

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 0/2] Immediate Values - jump patching update
    ... assembly ("g" constraints for all the expressions), ... That unconditional evaluation can easily entail memory reads and ... trace things, which i believe any usable kernel tracer must offer), ... runtime overhead that current markers have. ...
    (Linux-Kernel)
  • Re: [patch 0/2] Immediate Values - jump patching update
    ... kernel build, and thus the kernel cannot be self-sufficient / ... the DWARF data extraction (and systemtap-like $context-variable code ... assembly ("g" constraints for all the expressions), ... That unconditional evaluation can easily entail memory reads and ...
    (Linux-Kernel)
  • Re: Does Evaluation version work fine..?
    ... I have set g_OalLogmask = 0xffffffff in OEMInit() ... and below is the debug message I get on my debug console. ... Old or invalid version stamp in kernel structures - starting clean! ... could be due to evaluation version. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: if (pointer) ?
    ... based on expressions that return values. ... The idea that C takes ideas from Lisp at first seems ... and this is exploited for guarding against erroneous evaluation within the ... Just like the C avoiding evaluating p->property when p is null, ...
    (comp.lang.c)
  • Re: nested backquoting (newbie) question in Clisp
    ... more expressions, ... (defmacro nth-expr (n-expr &rest exprs) ... The problem is not that insufficient evaluation is applied, ... that ELT is a function and not a control construct. ...
    (comp.lang.lisp)
Loading