Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751750AbWIRPLI (ORCPT ); Mon, 18 Sep 2006 11:11:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751760AbWIRPLI (ORCPT ); Mon, 18 Sep 2006 11:11:08 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:56706 "EHLO mx2.mail.elte.hu") by vger.kernel.org with ESMTP id S1751750AbWIRPLF (ORCPT ); Mon, 18 Sep 2006 11:11:05 -0400 Date: Mon, 18 Sep 2006 17:02:31 +0200 From: Ingo Molnar To: "Frank Ch. Eigler" Cc: Paul Mundt , Mathieu Desnoyers , linux-kernel , Jes Sorensen , Andrew Morton , Tom Zanussi , Richard J Moore , Michel Dagenais , Christoph Hellwig , Greg Kroah-Hartman , Thomas Gleixner , William Cohen , "Martin J. Bligh" Subject: Re: tracepoint maintainance models Message-ID: <20060918150231.GA8197@elte.hu> References: <450D182B.9060300@opersys.com> <20060917112128.GA3170@localhost.usen.ad.jp> <20060917143623.GB15534@elte.hu> <20060917153633.GA29987@Krystal> <20060918000703.GA22752@elte.hu> <450DF28E.3050101@opersys.com> <20060918011352.GB30835@elte.hu> <20060918122527.GC3951@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060918122527.GC3951@redhat.com> User-Agent: Mutt/1.4.2.1i X-ELTE-SpamScore: -2.9 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.9 required=5.9 tests=ALL_TRUSTED,AWL,BAYES_50 autolearn=no SpamAssassin version=3.0.3 -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 0.5 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] -0.1 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3820 Lines: 107 * 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 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/