Re: Re: [PATCH 5/5] tracing: Add 'hash' event trigger command

[Masami Hiramatsu]

(2014/04/04 7:43), Tom Zanussi wrote:
> Hi Masami,
> 
> On Thu, 2014-04-03 at 17:59 +0900, Masami Hiramatsu wrote:
>> Hi Tom,
>>
>> (2014/03/27 13:54), Tom Zanussi wrote:
>>> Hash triggers allow users to continually hash events which can then be
>>> dumped later by simply reading the trigger file.  This is done
>>> strictly via one-liners and without any kind of programming language.
>>>
>>> The syntax follows the existing trigger syntax:
>>>
>>>   # echo hash:key(s):value(s)[:sort_keys()][ if filter] > event/trigger
>>>
>>> The values used as keys and values are just the fields that define the
>>> trace event and available in the event's 'format' file.  For example,
>>> the kmalloc event:
>>>
>>> root@ie:/sys/kernel/debug/tracing/events/kmem/kmalloc# cat format
>>> name: kmalloc
>>> ID: 370
>>> format:
>>>         field:unsigned short common_type;       offset:0;       size:2; signed:0;
>>>         field:unsigned char common_flags;       offset:2;       size:1; signed:0;
>>>         field:unsigned char common_preempt_count;       offset:3;       size:1;signed:0;
>>>         field:int common_pid;   offset:4;       size:4; signed:1;
>>>
>>>         field:unsigned long call_site;  offset:8;       size:4; signed:0;
>>>         field:const void * ptr; offset:12;      size:4; signed:0;
>>>         field:size_t bytes_req; offset:16;      size:4; signed:0;
>>>         field:size_t bytes_alloc;       offset:20;      size:4; signed:0;
>>>         field:gfp_t gfp_flags;  offset:24;      size:4; signed:0;
>>>
>>> The key can be made up of one or more of these fields and any number of
>>> values can specified - these are automatically tallied in the hash entry
>>> any time the event is hit.  Stacktraces can also be used as keys.
>>>
>>> For example, the following uses the stacktrace leading up to a kmalloc
>>> as the key for hashing kmalloc events.  For each hash entry a tally of
>>> the bytes_alloc field is kept.  Dumping out the trigger shows the sum
>>> of bytes allocated for each execution path that led to a kmalloc:
>>>
>>>   # echo 'hash:call_site:bytes_alloc' > /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
>>>   # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
>>
>> I like the basic idea :) but I'm confused the interface what you're introduced.
>> I suppose that the "trigger" file is for control triggers on the event, so that
>> user can check what trigger rules are set on the event and remove it.
>> But in this patch, that is also used for a data path.
>>
>> I'd like to suggest adding new "hash" file under events/GROUP/EVENT/, which is
>> only for dumping the hash data, and keep the "trigger" as a control path.
>> This makes users easier to build their own tools on the ftrace facility.
>>
> 
> I was really trying to avoid adding a new file - my thinking was that
> the trigger file is just sitting there doing nothing besides either
> listing available triggers when inactive or listing active triggers when
> active, which it would still do even if also providing a conduit for the
> output.

You don't need to avoid it unless it is really meaningless :)
Since the available triggers are limited and it doesn't relay on event
type, I think it is enough to prepare tracing/available_triggers.

> I agree that it would be cleaner to have a separate file, but I don't
> know if it's worth a dedicated file.  Another possibility would be to
> have it exist only when a hash trigger is active..

Agreed. That's a good idea :)

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@xxxxxxxxxxx


--
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/