[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Xenoprof in an HVM domain


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Steve Dobbelstein <steved@xxxxxxxxxx>
  • Date: Mon, 24 Apr 2006 15:08:26 -0500
  • Delivery-date: Mon, 24 Apr 2006 13:08:58 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

"Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx> wrote on 04/24/2006 02:02:41 AM:

> Hi Steve,
> As we know, xenoprof 2.0 is checked in xen-unstable for days.

Yes.  That's great.  Makes building Xenoprof support much easier.

> Now
> I'm writing a patch to add passive domain support (which exists in
> UP guest age) for smp guest.

Are you saying there is support for passive domains in Xenoprof?  If so, I
don't see it in xen-unstable.  (I just pulled changeset 9734.)  It's
mentioned in the docs, and some of it appeared in the 0.8.2 patch to the
oprofile utilities, but I don't see any support for passive domains in the
Xen hypervisor, the Linux sparse tree, nor the oprofile-0.9.1-xen.patch to
the oprofile utilities.  From what I can see, any events that are not going
to an active domain are dropped.  Or am I missing something?

> Using passive domain and my improvement
> in oprofile (I sent out before), we needn't change guest code and
> can tune hvm guest in a somewhat raw way -- PC samples from hv and
> guest kernel can be mapped to functions but all samples from
> application are only there as a whole. It's enough for tuning hvm
> performace for now.

If handling passive domains includes resolving symbols in the kernel
running in the HVM guest, then that would be sufficient for now.  I am
looking into performance issues with HVM domains -- networking, disk,
memory.  Much of that will be kernel code.

> You are proposing to add active domain support for hvm, right?

Yes.  For a complete profile we would want to include user space
applications.

> The
> apparent advantage is to tune hvm linux applications in future. It
> should be doable, like we've enabled vbd/vnif in hvm. And it needs
> more effort in hvm.
> Yes, Hypervcall, shared buffer and notification mechanism are all
> needed. For the last one, one of simple way is: 1) in hvm guest
> kernel, register for an unused IRQ line 2) in hv, inject that
> interrupt to hvm when needed. Or you can use a psydo PCI device in
> qemu to hold one irq number.

Thanks for the tips.

Steve D.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.