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

["Santos, Jose Renato G (Jose Renato Santos)" <joserenato.santos@xxxxxx>]

>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
>> William Cohen
>> Sent: Monday, April 11, 2005 1:27 PM
>> To: xen-devel@xxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
>> 

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