Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756659AbdCUHey (ORCPT ); Tue, 21 Mar 2017 03:34:54 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:36610 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753210AbdCUHda (ORCPT ); Tue, 21 Mar 2017 03:33:30 -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: Alexander Shishkin Date: Tue, 21 Mar 2017 09:33:28 +0200 X-Google-Sender-Auth: Qxu49ARBxoxCg7b-e1rX5Ww3nt4 Message-ID: Subject: Re: [PATCH] stm class: Document the stm_ftrace To: Chunyan Zhang Cc: Alexander Shishkin , 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: 1804 Lines: 46 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 the corresponding section, to avoid KASLR fun) instead of the actual string? This would require a kernel binary on the decoding end, though. Regards, -- Alex