Re: get the mapping of <key, syscallname>

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

guanglei wrote:

> [...]
> But one disadvantage is that if using "syscall.*", then every syscall 
> will use a different function to be its probe handler. 

There are two separate opportunities for improvement here, and both of
them are going to get some attention.  

First, a lot of essentially duplicated registration, unregistration,
and entry routines are being generated.  These can be collapsed into
one triplet of functions per type (one for all kprobes, one for all
kretprobes, etc.).  This will remove hundreds of functions of the
"syscall.*"-originated C code, and should make a drastic difference as
to performance.

Second, probe handlers constructed from distinct probe/alias bodies
may be collapsed, if they turn out to be equivalent after
optimization.  One might think of it as a generalization of graydon's
"flavour" calculations in tapsets.cxx.

Together, these two tapset-level optimizations should bring the
"abstraction penalty" way down.

> [Regarding parsing CONTEXT->probe_point: ...]  As discovered in the
> former analysis of LKET, strpbrk() is one of the most costly
> operations. It is a kernel function and is called by strsep() to get
> the current syscall name.  I use another way to get the syscall
> name: [...]

It may be worth addressing this a totally different way too.  The
translator could provide another variable, a sibling of
CONTEXT->probe_point.  It would contains the equivalent of
probefunc(), at least for those probes that have a "synchronous"
binding to a PC address, which kprobes-based ones do.  It could be
statically initialized the same way as probe_point, and the
probefunc() tapset function could be extended to look at that field
first.  No strpbrk or iteration at all then.

- FChE