Messages in this thread | | | Date | Mon, 18 Sep 2006 17:02:31 +0200 | From | Ingo Molnar <> | Subject | Re: tracepoint maintainance models |
| |
* 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/
| |