[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.043 / U:9.664 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site