Re: New kernel marker wiki page

[fche at redhat dot com (Frank Ch. Eigler)]

"K.Prasad" <prasad@linux.vnet.ibm.com> writes:

> [...]
> > "How are marker arguments handled that are structure pointers?
> >
> > Not well. Because systemtap has no DWARF information for marker arguments, it
> > really doesn't know what type they are. [...]

> Solutions to this problem, as detailed in the wiki, and their shortcomings as I
> see are [...]

... are fairly straightforward to understand.


> * Solution proposed - "go ahead and put the interesting structure fields in the
> marker itself" - From the previous discussions related to marker patches
> (submitted for RCU debugging infrastructure), it was apparent that the community
> desired the least amount of instrumentation code in the kernel. This would be
> more pronounced when markers are proposed in critical code regions which would
> have in the performance of the system. [...]

It turns out that adding extra marker parameters is essentially a
performance no-op, consider that even the evaluation of those
parameters is placed inside an unlikely() / -freorder-blocks type
block.  One vs. several makes little difference.

That said, one has to use judgement and context.  A few key parameters
are not too bad; a dozen is probably excessive.


> [...] Given these usability issues for SystemTap over markers in the
> absence of DWARF information, would it still be a good idea to
> exclude DWARF information or are there other plans to mitigate them?

Remember, it's not that we *exclude* dwarf data.  For markers, don't
have any natural references as to where to start looking.  There is no
requirement that a marker name be unique across the kernel.  There is
no single PC address associated with a given marker call site, which
is what we'd need to look in dwarf for variables/locations.  There is
not even a single compilation unit.  Even if we could map a marker
name to a set of PCs, at the time that a marker callback function is
received, we don't know which one (call site) it was.  We also don't
get a copy of pt_regs to start extracting registers from.

Now, if we restrict the complexity a great deal, and are willing to
settle for heuristics, we may be able to do something.  But it's
certainly not a trivial matter of "not excluding" dwarf information.


- FChE