All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Chunyan Zhang <zhang.chunyan@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, Mark Brown <broonie@linaro.org>
Subject: Re: Ftrace Data Export
Date: Mon, 05 Jun 2017 09:17:59 +0300	[thread overview]
Message-ID: <87mv9nt0tk.fsf@linux.intel.com> (raw)
In-Reply-To: <CAG2=9p_-9LzcckbFBvd2H_-jzbr_kV0+puf=WRDQVK6Jy15d6w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]


Hi,

Chunyan Zhang <zhang.chunyan@linaro.org> writes:
>> Maybe that's why they consider it an extra overhead? Have you considered
>> off-loading raw data for further post processing?
>
> Yes, that's also the way off-loading function trace has been implemented now.
> And like you said below, I also believe we can do the similar things
> to other tracers.
> I'd like to do this, but I have some other tasks in hands recently :-(

fair enough

>>>> function_graph, hwlat, irqsoff and all the other possibilities?
>>>
>>> I haven't thought about these clear enough :)
>>> Any suggestion?
>>
>> I think we should be able to export everything and anything :-p But, of
>> course, we would need tooling to decode it after the fact.
>
> Yes, tools for decoding these raw data with kernel binary is one
> thing, and how large storage STM can use to collect traces will also
> affect how much value doing this will bring in and perhaps will
> influence how we implement off-loading ftrace to trace export.
>
> Since I haven't played Intel STM, how large are the storages connected
> to STM on Intel platforms in general?

that I don't know :-) My interest here is to off-load it via USB. I
suppose Alex knows the size of STM storage on Intel systems.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

      reply	other threads:[~2017-06-05  6:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-17  8:08 Ftrace Data Export Felipe Balbi
2017-05-17 12:45 ` Chunyan Zhang
2017-06-02 10:24   ` Felipe Balbi
2017-06-02 12:22     ` Chunyan Zhang
2017-06-05  6:17       ` Felipe Balbi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mv9nt0tk.fsf@linux.intel.com \
    --to=felipe.balbi@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=broonie@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=zhang.chunyan@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.