RE: [PATCH] Xenoprof: Enabling performance profiling in Xen

RE: [PATCH] Xenoprof: Enabling performance profiling in Xen

[Santos, Jose Renato G (Jose Renato Santos)]

>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com 
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
>> William Cohen
>> Sent: Monday, April 11, 2005 1:27 PM
>> To: xen-devel@lists.xensource.com
>> Cc: oprofile-list
>> Subject: [Xen-devel] [PATCH] Xenoprof: Enabling performance 
>> profiling in Xen
>> 
>> 
>> I took a quick look at the patches for supporting profiling 
>> in Xen and I 
>> have some questions about the patches.
>> 
>> -Do all domains have to use the same setup for the performance 
>> monitoring counters? Or is there some virtualization of the 
>> performance 
>> counters?
>> 
    Right now, there is no virtualization of the hardware performance
    counters. Our goal was to have a system wide profiling capability
    that could enable us understand better the behavior of Xen.
    Currently, only one profiling session can be run at a time and the 
    initiator domain for that session (typicaly domain 0) is the 
    domain that specify the performance events to be monitored.
    All other profiled domains just collect and decode samples of the
    same events.
    It would be nice to have hardware performance counter virtualization
    but it is not on our priority list.


>> -How is this going to interact with other performance monitoring 
>> infrastructure such as perfctr and perfmon? Or is the design 
>> going to 
>> need to be significantly revised for other performance monitoring 
>> interfaces? I like OProfile as much as anyone else, but I 
>> would like to 
>> see the Xen support allow the other interfaces to 
>> performance monitoring 
>> hardware to work.
>> 
   Our focus was mostly on enabling Oprofile to work on Xen. 
   Significant changes will be required for other performance 
   monitoring infraestructure, although some of the code could 
   be re-used. We are not planning to work on these in the
   near future. 

>> -It appears that the multiple samples can be queued up in the 
>> hypervisor. In the OProfile kernel support when a process 
>> exits there is 
>> a flush of the per cpu buffers to make sure that the VMAs 
>> are mapped to 
>> files and offsets before the the mappings are lost. Should 
>> there be a 
>> flush of the samples from the hypervisor to make sure that 
>> they are read 
>> out before the process exits and the memory maps are lost?
>> 

   Samples are only queued for passive domains (on the initiator
   queue) (this is done to avoid waking up the initiator to process 
   samples that happen when running passive domains), or when executing 
   a critical part of the Xen code. PC samples for passive domains
   are not decoded into a file/offset and thus there is no issue.
   When the sample happens at a critical session of Xen, there
   is no issue either, since the PC refers to code in the hypervisor.
   When a counter overflows in an active domain, we guarantee that
   the samples in the hypervisor are transferred to the domain
   CPU  buffer, before the domain continue execution
   (i.e. virtually no queue).
   Thus there is no process context switch or exiting processes
   in between a counter overflow and the receipt of a sample in
   the domain CPU buffer (for active domains). The normal flush
   of CPU buffer in the domain when a process exit still applies,
   as in standard linux.

   
>> -OProfile analysis tools expect the exectuable to be around when 
>> analyzing the sample files. Is the oprofile user space making the 
>> assumption that the domains have the same executables for 
>> the active and 
>> passive domains? Things could be messy if the domains are different, 
>> e.g. Fedora Core 3 domain and a Rawhide domain.
>> 

   Right now, passive domains samples do not get assigned to any 
   executable file. They are assigned to a general category domain_n
   (coarse granularity profiling). (i.e. no executable file is needed
   by analysis tools for passive domains). Active domains 
   keep their own sample files and thus there is no issue either.
 
   Ian suggested that we add support to enable the user to specify
   (at the initiator)  a file with symbol mappings for passive domains.
   This may be added in a future version to enable symbol mapping
   for the kernel, but user level symbols would still not be decoded
   for passive domains.

>> -Should get rid of 
>> xen-2.0.5/xen/arch/x86/oprofile/#Makefile# in the xen 
>> hypervisor patch.
>> 
>> 
   Sure! Sorry, I missed that.

   Renato 

  PS: For context, those who did not see the original post, please
check:
 
http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00256.html

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

Re: [Xen-devel] [PATCH] Xenoprof: Enabling performance profiling in Xen

[John Levon]

On Mon, Apr 11, 2005 at 03:37:57PM -0700, Santos, Jose Renato G (Jose Renato Santos) wrote:

> http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00256.html

Where can I get the diff against oprofile userspace source, plus a diff
of the changes to the kernel driver?

(It'd be really handy if somebody wrote up a little bit about Xen (no
idea what a domain is) for us OProfile people too)

regards
john


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [Xen-devel] [PATCH] Xenoprof: Enabling performance profiling in Xen

[William Cohen]

John Levon wrote:
> On Mon, Apr 11, 2005 at 03:37:57PM -0700, Santos, Jose Renato G (Jose Renato Santos) wrote:
> 
> 
>>http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00256.html
> 
> 
> Where can I get the diff against oprofile userspace source, plus a diff
> of the changes to the kernel driver?
> 
> (It'd be really handy if somebody wrote up a little bit about Xen (no
> idea what a domain is) for us OProfile people too)

Xen is a virtualization system. It allows multiple domains (instances of 
the OS) to run on a computer using a hypervisor. Think of a domain as a 
Virtual Machine in the old 360 mainframes. Thus, a physical machine 
could appear to be multiple logical machines, each with a different disk 
image and installation running on it.

Xen uses paravirtualization, so the kernel needs to be modified to make 
calls to the hypervisor rather than directly touch hardware like the 
memory management unit. This is bit different than VMware which emulates 
the machine and the OS doesn't need to be modified. However, Xen has 
better performance a a result of this. Note that user applications do 
not need to be modified to run on Xen. There is more information about 
Xen at:

http://xen.sf.net/

Here are the start of the threads in the xen-devel mailing list 
discussing the patches to provide oprofile support:

http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00256.html
http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00257.html
http://lists.xensource.com/archives/html/xen-devel/2005-04/msg00259.html

-Will


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click