lkml.org 
[lkml]   [2009]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Multiple Tracers
CC: Arnaldo Carvalho de Melo <acme@redhat.com>

Ingo Molnar wrote:
> * Steven Whitehouse <swhiteho@redhat.com> wrote:
>
>> Hi,
>>
>> On Wed, 2009-04-08 at 15:53 +0200, Ingo Molnar wrote:
>>> * Steven Whitehouse <swhiteho@redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> A little while back I posted a RFC patch which added gfs2 glock
>>>> tracing to blktrace. There was a suggestion that I should look
>>>> instead at the generic tracing code and add a new tracer, but I've
>>>> come up with a couple of issues along the way.
>>>>
>>>> I think from what I can see that its only possible to run a single
>>>> tracer at once, so running blktrace (for example) would preclude
>>>> me from also tracing gfs2's glocks at the same time. Also, I can
>>>> see no mechanism by which I could ensure the sequencing between
>>>> the blktrace and glock traces other than exporting the blktrace
>>>> sequence number, even if running multiple tracers at the same time
>>>> was possible.
>>> There's a recent addition: the EVENT_TRACE() facility. Would that
>>> suit your purposes?
>>>
>>> Ingo
>> If I can get both blktrace and glock trace info from it, then yes.
>> I thought that the blktrace output went either via the original
>> relayfs path, or via its own tracer so that it wasn't possible to
>> use it and the event trace facility at the same time, unless I use
>> blktrace via relayfs. From what I've read I thought that probably
>> the relayfs interface for blktrace might eventually be removed in
>> favour of the generic tracing interface, but I'm not 100% sure of
>> that, so perhaps someone can confirm the plans in that area?
>
> Tom Zanussi (Cc:-ed) recently converted the blktrace tracepoints to

I guess you mean Arnaldo <acme@redhat.com> ;)

> a tracing framework - and i think much of that could be reused to
> add EVENT_TRACE() tracepoints to blktrace too.
>
> Tom, what's your take on this?
>
> In general, this is the direction we want to take: EVENT_TRACE()
> tracepoints that can be used in a generic way, in any tracer.
>

Actually we've planed to do this, and for other tracers.

--
Zefan


\
 
 \ /
  Last update: 2009-04-09 04:13    [W:0.306 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site