public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	David Sharp <dhsharp@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>,
	Ingo Molnar <mingo@redhat.com>,
	yrl.pp-manager.tt@hitachi.com,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Re: Re: [PATCH V2 1/1] kvm/vmx: Add a tracepoint write_tsc_offset
Date: Mon, 10 Jun 2013 17:28:23 -0300	[thread overview]
Message-ID: <20130610202823.GC31409@amt.cnet> (raw)
In-Reply-To: <20130610163834.GG29022@redhat.com>

On Mon, Jun 10, 2013 at 07:38:34PM +0300, Gleb Natapov wrote:
> > Guest traces contain vcpu number and not pid (because guest is unaware
> > of host PID).
> > 
> No, guest trace is just a regular ftrace done inside a guest. It contains
> guest's PIDs which is useless for host. 

# tracer: nop
#
# entries-in-buffer/entries-written: 5333/5333   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |

Traces contain CPU ID.

> I do not know how exactly guest traces are transfered to a host, if
> each vcpu buffer is transfered separately host can figure out what
> trace entry belong to which vcpu based on what buffer the trace is in.
> But the information about what buffer belongs to which vcpu id should
> be transfered to a host somehow too.
> 
> > > >                                                 However, when we
> > > > focus on output data of the write_tsc_offset event, it is difficult to
> > > > directly understand contents of the data if vcpu number information is
> > > > not included. So, including the information is useful, I think.
> > > > 
> > > How your tool does it now?
> > 
> > It merges guest trace with host trace (by converting the TSC timestamp 
> > in the guest trace to host TSC using tsc_offset information).
> > 
> I mean how it does it now without vcpu id. The answer is that it works
> for only one vcpu now.

Yes.

> > By not recording vcpu ID in the tsc_offset trace, it is necessary to
> > supply the tool with PID<->VCPU_id tuples for translation (so its an
> > additional step required, and it makes trace merge impossible
> > if the information is not available).
> The tool needs PID<->VCPU_id tuples to do the merging of any trace
> entry. Without that it does not know how to interpret entry timestamps
> (which offset to use). Apparently it will get this information from
> vmentry trace point. What is so special about tsc_offset tracing that
> it needs to contain vcpuid by itself.

If the tsc_offset tracepoint contains vcpu ID, its possible to lookup
guest trace entry (which contains CPU ID), and match on that.

Without that, PID<->VCPU_id tuples are necessary. Yes?


  reply	other threads:[~2013-06-10 20:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-04  8:36 [PATCH V2 0/1] kvm/vmx: Output TSC offset Yoshihiro YUNOMAE
2013-06-04  8:36 ` [PATCH V2 1/1] kvm/vmx: Add a tracepoint write_tsc_offset Yoshihiro YUNOMAE
2013-06-06  0:23   ` Marcelo Tosatti
2013-06-06 11:33     ` Gleb Natapov
2013-06-06 21:43       ` Marcelo Tosatti
2013-06-07  5:22       ` Yoshihiro YUNOMAE
2013-06-07 21:55         ` Marcelo Tosatti
2013-06-09 11:14         ` Gleb Natapov
2013-06-10  9:30           ` Yoshihiro YUNOMAE
2013-06-10 10:05             ` Gleb Natapov
2013-06-10 11:37               ` Yoshihiro YUNOMAE
2013-06-10 14:04               ` Marcelo Tosatti
2013-06-10 16:38                 ` Gleb Natapov
2013-06-10 20:28                   ` Marcelo Tosatti [this message]
2013-06-11  6:50                     ` Gleb Natapov
2013-06-11  9:26                       ` Yoshihiro YUNOMAE
2013-06-04  8:38 ` [EXAMPLE] tools: a tool for merging trace data of a guest and a host Yoshihiro YUNOMAE

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=20130610202823.GC31409@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=dhsharp@google.com \
    --cc=gleb@redhat.com \
    --cc=hidehiro.kawai.ez@hitachi.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=yoshihiro.yunomae.ez@hitachi.com \
    --cc=yrl.pp-manager.tt@hitachi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox