From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932388AbdJJPpm (ORCPT ); Tue, 10 Oct 2017 11:45:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:54910 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932262AbdJJPpk (ORCPT ); Tue, 10 Oct 2017 11:45:40 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C7C6621904 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Tue, 10 Oct 2017 11:45:37 -0400 From: Steven Rostedt To: Jessica Yu Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton , Rusty Russell , Joel Fernandes Subject: Re: ftrace: Save module init functions kallsyms symbols for tracing Message-ID: <20171010114537.596e14e2@gandalf.local.home> In-Reply-To: <20171009155100.0719ef85@gandalf.local.home> References: <20170919142801.151866799@goodmis.org> <20170919143533.629528624@goodmis.org> <20171006205514.wcnt22y7w7oziq5a@redbean> <20171009155100.0719ef85@gandalf.local.home> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 9 Oct 2017 15:51:00 -0400 Steven Rostedt wrote: > > Using the snd_seq example from patch 03, I get the same human-readable trace: > > > > # tracer: function > > # > > # _-----=> irqs-off > > # / _----=> need-resched > > # | / _---=> hardirq/softirq > > # || / _--=> preempt-depth > > # ||| / delay > > # TASK-PID CPU# |||| TIMESTAMP FUNCTION > > # | | | |||| | | > > modprobe-12748 [005] .... 138.964923: alsa_seq_init <-do_one_initcall > > modprobe-12748 [005] .... 138.964924: client_init_data <-alsa_seq_init > > modprobe-12748 [005] .... 138.964924: snd_sequencer_memory_init <-alsa_seq_init > > modprobe-12748 [005] .... 138.964924: snd_seq_queues_init <-alsa_seq_init > > modprobe-12748 [005] .... 138.964924: snd_sequencer_device_init <-alsa_seq_init > > modprobe-12748 [005] .... 138.964956: snd_seq_info_init <-alsa_seq_init > > modprobe-12748 [005] .... 138.964956: create_info_entry <-snd_seq_info_init > > modprobe-12748 [005] .... 138.964958: create_info_entry <-snd_seq_info_init > > modprobe-12748 [005] .... 138.964959: create_info_entry <-snd_seq_info_init > > modprobe-12748 [005] .... 138.964960: snd_seq_system_client_init <-alsa_seq_init > > modprobe-12748 [005] .... 138.964960: snd_seq_create_kernel_client <-snd_seq_system_client_init > > > > In addition, the module init functions appear in /proc/kallsyms as > > well. Thoughts? Would saving init symbol information in the module > > symtab be sufficient for ftrace? Hi Jessica, Are you going to have time to work on this more? Should we allow multiple init addresses to appear, or should there be some check to see if they already exist, and remove the older one? Ideally, I could have a way to know if a module init function was traced and its address was stored in a ring buffer, and keep the init mapping around and used for that buffer, and free it when the buffer is cleared, and there's no other buffers that have a reference to it. But I need to find a low overhead way to account for this. Personally, I would rather have the mappings saved in the symbol tables in the module code. If we can come up with a better module way, I'll convert to that. But as I want to get this code upstream by 4.15, I'm going to continue with what I have. Thoughts? -- Steve