xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Paul Sujkov <psujkov@gmail.com>,
	xen-devel@lists.xen.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: xentrace, xenalyze
Date: Wed, 24 Feb 2016 14:41:19 +0000	[thread overview]
Message-ID: <56CDC10F.8020003@citrix.com> (raw)
In-Reply-To: <CA+KUHvyH57Ab7c=Hk-vQd2ANrgGnNnLef=c43D==w2QL48s2Gw@mail.gmail.com>

On 24/02/16 13:21, Paul Sujkov wrote:
> Hi,
> 
> I'm from GlobalLogic team that uses Xen as a base for an automative
> platform. Got few questions regarding Xen tracing and it seems that
> existing documentation is rather limited.
> 
> At the previous Xen Hackathon I was talking about shared (mediated
> pass-through) GPU concept for ARM; it's working well, but still has
> performance issues, and some of them seem to be correlated to other Xen
> subsystems, but it's not obvious why so (e.g. turning off pv real time
> clock driver gives us a significant boost in overall graphics performance).
> So, I'm looking for two things here actually:
> 
> 1. to understand how can I use xenalyze to find bottlenecks in the system
> at the moment
> 2. to add VGPU scheduler traces to Xen trace subsystem, xenbaked, xentrace
> and xenalyze
> 
> Some insights into the second question can be found in RTDS scheduler
> patches (it adds a few of it's own trace events and uses generic scheduler
> tracing); however, it uses already functioning scheduler tracing subsystem
> which is VCPU specific and is not suitable for VGPU, and there are no
> visible patches to xenalyze to parse these traces out.

Thanks, Paul.

First of all: I'm not sure anyone has used xenbaked in ages; xentrace
itself is just a daemon to shovel data from the hypervisor into a file
-- it doesn't need to know anything about what's being traced (for the
most part).  That just leaves adding traces to the hypervisor,
xentrace_format, and xenalyze.

I think actually the first thing you might need to do is to get the
xentrace infrastructure working on ARM.  At least at some point there
was no way for dom0 to map the xentrace pages (but that may have changed).

After that, the next thing would be to add the equivalent of VMEXIT and
VMENTRY traces in the hypervisor on ARM guest exit and entry, and then
add support for analyzing that data to xenalyze.

Once you've got that done, then you just add in extra tracing
information as you need to drill down and figure out what's going on. :-)

 -George

  reply	other threads:[~2016-02-24 14:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24 13:21 xentrace, xenalyze Paul Sujkov
2016-02-24 14:41 ` George Dunlap [this message]
2016-02-24 15:24   ` Paul Sujkov
2016-02-24 15:53     ` Dario Faggioli
2016-02-24 15:58     ` George Dunlap
2016-02-24 17:58       ` Paul Sujkov
2016-02-24 14:51 ` Dario Faggioli
2016-02-24 16:00   ` Paul Sujkov
2016-02-24 16:19     ` George Dunlap

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=56CDC10F.8020003@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=psujkov@gmail.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).