On Mon, Mar 31, 2014 at 1:19 AM, Andi Kleen <a...@firstfloor.org> wrote:
>> See test/benchmark/cmp_table.sh, that script compare
>
> Is that a realistic tracing scenario?
>
Yes, it's quite common to use string key in dynamic tracing tool,
for example, See samples/userspace/glibc_func_hist.kp
var s = {}
trace probe:/lib64/libc.so.6:* {
s[probename] += 1
}
trace_end {
print_hist(s)
}
Result:
Tracing... Hit Ctrl-C to end.
^C
value ------------- Distribution ------------- count
_IO_sputbackc |@@ 108344
__GI__IO_sputbackc |@@ 107768
_IO_default_xsputn | 46639
__GI__IO_default_xsputn | 46624
free | 36871
__libc_free | 36841
cfree | 36841
__free | 36811
__cfree | 36811
__GI___libc_free | 36804
____strtoull_l_internal | 28670
__GI_____strtoul_l_internal | 28670
__GI_____strtoull_l_internal | 28518
____strtoul_l_internal | 28518
strchrnul | 27763
__strchrnul | 27741
_IO_putc | 27589
__GI__IO_putc | 27589
putc | 27589
... |
Above script output histogram of glibc function call, you will know
which function will be called frequently, a very useful script.
'probename' return probe name string, then insert table as key.
The magic of above script is there have no string copy and string hash
in probe context, because probename string is interned.
>> table operation between ktap with stap, the result is very
>> inspiring, ktap table operation overhead is quite lower than
>> stap, especially when use constant string key.
>
> Ok fair enough.
>
>>
>> But I agree with you partly, because in some cases we don't
>> want/need to interning all string, for example:
>> trace xxx:yyy {
>> var str = cast("char *", arg1)
>> print(str)
>> }
>>
>> In above case, arg1 is a long kernel string, and no table insert,
>> so definitely no need to interned, so we need to add
>> KTAP_TRAWSTR to represent these values.
>
> Please don't make it more complicated. If there's a good rationale
> for interning it' ok to use always.
>
> It would be better to find ways to simplify things.
>
Definitely, the reason I implement ktap based on lua is the simplicity
and efficiency of lua.
The whole bytecode design and value type is very simple, it could
build a complete safe sandbox for kernel scripting, and easy to
extend to fulfill our need(like multi-key table, aggregation)
Thanks.
Jovi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
