Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757233AbdCUM1b (ORCPT ); Tue, 21 Mar 2017 08:27:31 -0400 Received: from mail-qt0-f195.google.com ([209.85.216.195]:36127 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756497AbdCUM12 (ORCPT ); Tue, 21 Mar 2017 08:27:28 -0400 MIME-Version: 1.0 In-Reply-To: References: <1489992438-14228-1-git-send-email-chunyan.zhang@spreadtrum.com> <87wpbk2ohp.fsf@ashishki-desk.ger.corp.intel.com> From: Chunyan Zhang Date: Tue, 21 Mar 2017 20:26:25 +0800 Message-ID: Subject: Re: [PATCH] stm class: Document the stm_ftrace To: Alexander Shishkin Cc: Chunyan Zhang , "linux-doc@vger.kernel.org" , Linux Kernel Mailing List , Mathieu Poirier , nicolas.guion@st.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2282 Lines: 61 On 21 March 2017 at 15:33, Alexander Shishkin wrote: > On 21 March 2017 at 07:57, Chunyan Zhang wrote: >> On 20 March 2017 at 19:09, Alexander Shishkin >> wrote: >>> Chunyan Zhang writes: >>> >>>> Hi Alex, >>>> >>>> On 20 March 2017 at 16:49, Alexander Shishkin >>>> wrote: >>>>> Hi Chunyan, >>>>> >>>>> A couple of clarifications: iirc this applies to the function tracer >>>>> of ftrace, right? Does it make sense to mention that? Also, are you >>>> >>>> Right, only applies to the function tracer currently (actually only >>>> function address and parent function address of Function tracer is >>>> recorded into STM, I mean it doesn't include like "pid" "task name" >>>> "cpu-id" these information right now). It makes sense to mention >>>> function tracer, I will address that. >>> >>> Thanks! >>> >>>>> planning to support other ftrace payloads like trace_printk()s? >>>> >>>> No plan so far, but I think I can consider to do that, it depends on >>>> how many people think that are helpful. >>>> What do you think? >>> >>> Well, I myself almost never use function tracer, but I do use >>> tracepoints/trace_printk()s. I'm *guessing* that everybody who's >> >> In fact I had implemented exporting tracepoints to STM and tried >> upstreaming that, but Steven Rostedt and Ingo expressed their worries >> on that would introduce a considerable impact on Ftrace fast path >> since a tracepoint basically was a string which was too long to be >> written to STM with some acceptable impact on fast path, so I stopped >> upstreaming that feature. > > Did we ever consider writing a string pointer (or even on offset into Regarding to the pointer, you mean event pointer in Ftrace ring buffer? I considered recording trace_events' ring buffer address which their meta data is stored, my concern was how we should do if ring buffer overwriting happened. > the corresponding section, to avoid KASLR fun) instead of the actual > string? This would require a kernel binary on the decoding end, > though. Decoding function traces supported currently from STM also needs kernel binary :) Thanks, Chunyan > > Regards, > -- > Alex