Re: tracepoint maintainance models

[Ingo Molnar <mingo@elte.hu>]

* Frank Ch. Eigler <fche@redhat.com> 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 
distribution:

     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.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/