Message-ID: <20060918150231.GA8197@elte.hu>
Date:	Mon, 18 Sep 2006 17:02:31 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Paul Mundt <lethal@...ux-sh.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jes Sorensen <jes@....com>, Andrew Morton <akpm@...l.org>,
	Tom Zanussi <zanussi@...ibm.com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>,
	"Martin J. Bligh" <mbligh@...igh.org>
Subject: Re: tracepoint maintainance models


* Frank Ch. Eigler <fche@...hat.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists