[lkml]   [2006]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: tracepoint maintainance models

* Frank Ch. Eigler <> wrote:

> > For dynamic tracers no such 'parameter preparation' instructions
> > would need to be generated by gcc. (thus for example the runtime
> > overhead would be lower for inactive tracepoints)
> Any such additional code would be small, plus if properly marked up
> with unlikely() and compiled with -freorder-blocks, it would all be
> out-of-line. This small cost could be worth the added benefit of
> systemtap being able to probe that point without debugging information
> present, and avoiding its slow & deliberate way of accessing
> target-side variables like $x. (The slow & deliberate part comes in
> from the need to check any pointer dereferences involved.)

yeah, agreed. It seems Mathieu agrees that more synergy between
SystemTap and LTTng is possible and desirable, so i think that's a good
basis to step forward: lets figure out an API for static markups.

The current LTTng static markup APIs have the following form and

82 trace_kernel_trap_exit
35 trace_kernel_trap_entry
8 trace_real_syscall_exit
8 trace_real_syscall_entry
7 trace_kernel_arch_syscall_entry
6 trace_kernel_stack_dump
6 trace_kernel_arch_syscall_exit
5 trace_process_kernel_thread
5 trace_ipc_call
3 trace_process_stack_dump
3 trace_kernel_irq_exit
3 trace_kernel_irq_entry
3 trace_fs_write
3 trace_fs_read
2 trace_timer_expired
2 trace_locking_irq_save
2 trace_locking_irq_restore
2 trace_locking_irq_enable
2 trace_locking_irq_disable
2 trace_kernel_tasklet_exit
2 trace_kernel_tasklet_entry
2 trace_fs_seek
2 trace_fs_exec
2 t_log_event
1 trace_timer_softirq
1 trace_timer_set_timer
1 trace_timer_set_itimer
1 trace_statedump_enumerate_modules
1 trace_statedump_enumerate_interrupts
1 trace_socket_sendmsg
1 trace_socket_recvmsg
1 trace_socket_create
1 trace_socket_call
1 trace_real_syscall32_entry
1 trace_process_wakeup
1 trace_process_signal
1 trace_process_schedchange
1 trace_process_kernel_thread__
1 trace_network_packet_out
1 trace_network_packet_in
1 trace_network_ip_interface_dev_up
1 trace_network_ip_interface_dev_down
1 trace_memory_swap_out
1 trace_memory_swap_in
1 trace_memory_page_wait_start
1 trace_memory_page_wait_end
1 trace_memory_page_free
1 trace_memory_page_alloc
1 trace_kernel_soft_irq_exit
1 trace_kernel_soft_irq_entry
1 trace_ipc_shm_create
1 trace_ipc_sem_create
1 trace_ipc_msg_create
1 trace_fs_select
1 trace_fs_poll
1 trace_fs_open
1 trace_fs_ioctl
1 trace_fs_data_write
1 trace_fs_data_read
1 trace_fs_close
1 trace_fs_buf_wait_start
1 trace_fs_buf_wait_end

that's 235 markups (i'm sure the list has a few false positives, but
this is the rough histogram).

Right now the name and type of the event is encoded in the trace
function name, which i dont really like. I think markups are less
intrusive visually in the following form:

MARK(trace_fs_data_read, fd, count, len, buf);

but no strong feelings either way.

also, there should be only a single switch for markups: either all of
them are compiled in or none of them. That simplifies the support
picture and gets rid of some ugly #ifdefs. Distro kernels will likely
enable all of thems, so there will be nice uniformity all across.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-09-18 17:13    [W:0.159 / U:0.984 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site