Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756464AbdCUGAA (ORCPT ); Tue, 21 Mar 2017 02:00:00 -0400 Received: from mail-qt0-f171.google.com ([209.85.216.171]:35802 "EHLO mail-qt0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756259AbdCUF75 (ORCPT ); Tue, 21 Mar 2017 01:59:57 -0400 MIME-Version: 1.0 In-Reply-To: <87wpbk2ohp.fsf@ashishki-desk.ger.corp.intel.com> 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 13:57:59 +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: 1700 Lines: 48 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. Thanks, Chunyan > subsystem implement tracepoints will be interested in those. > > I confess that I haven't yet looked at the code properly, so I'm a don't > have a picture of what it will take to implement these. > > Regards, > -- > Alex