(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...@hitachi.com -- 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/