|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH] Xenoprof: Enabling performance profiling in Xen
>> -----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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |