Xen devel - Jul 2007 - xenoprof support patch issue for oprofile 0.9.3

Oprofile 0.9.3 released yesterday. The patches for xenoprof are not currently in
the upstream oprofile. I noticed that one of the defines in the xenoprof patches
for oprofile has a define DOMAIN_SWITCH_CODE in daemon/opd_interface.h which 
conflicts with SPU_PROFILING_CODE. This conflict will need to be worked out.



-Will

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

Will,

Thanks for pointing this out.
I will work on a patch to fix this
By the way, it would be nice to have the xenoprof patches merged into
Oprofile CVS tree.
John Levon is not happy with the way passive domain samples are stored
now and I don''t have the bandwidth (and knowdledge of user level
Oprofile code) to do the right fixes. This has prevented the patches to
be merged. It would be nice if we can find a volunteer to do the right
fixes and have the code merged. I would be happy to assist anyone who
volunteers for the task. What we need is a way of separating samples
from different domains and change to the tools to understand this new
information.

Thanks

Renato 
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com 
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
>> William Cohen
>> Sent: Tuesday, July 17, 2007 11:47 AM
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] xenoprof support patch issue for oprofile 0.9.3
>> 
>> Oprofile 0.9.3 released yesterday. The patches for xenoprof 
>> are not currently in the upstream oprofile. I noticed that 
>> one of the defines in the xenoprof patches for oprofile has 
>> a define DOMAIN_SWITCH_CODE in daemon/opd_interface.h which 
>> conflicts with SPU_PROFILING_CODE. This conflict will need 
>> to be worked out.
>> 
>> 
>> 
>> -Will
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Santos, Jose Renato G wrote:
> Will,
> 
> Thanks for pointing this out.
> I will work on a patch to fix this
> By the way, it would be nice to have the xenoprof patches merged into
> Oprofile CVS tree.
> John Levon is not happy with the way passive domain samples are stored
> now and I don''t have the bandwidth (and knowdledge of user level
> Oprofile code) to do the right fixes. This has prevented the patches to
> be merged. It would be nice if we can find a volunteer to do the right
> fixes and have the code merged. I would be happy to assist anyone who
> volunteers for the task. What we need is a way of separating samples
> from different domains and change to the tools to understand this new
> information.
> 
> Thanks
> 
> Renato 
Hi Renato,

Definitely want to avoid having separate patches to avoid just this type of 
problem. Getting patches upstream is the way to go on that.

Do you have a pointer to the email discussion about the passive domain sample 
storage? Passive means that the domain is not taking the samples and storing 
them in the domain, right?

One of the things that I have noticed on my previous experiments with the 
xenoprof is there are quite a few steps to setup xenoprof. The user has to do 
setup on each domain. Ideally it would be nice to be able to just do one setup 
in the host domain and then have that information be propagated to the guest 
domains. Similarly the analysis would be nice to get one over all picture of all
the domains. Clusters have a similar issue; one doesn''t want to manage
machine
individually. However clusters may have different hardware for the various nodes
in the cluster. With xen the only difference could be the software.

-Will

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

>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com 
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
>> William Cohen
>> Sent: Friday, July 20, 2007 7:44 AM
>> To: Santos, Jose Renato G
>> Cc: xen-devel@lists.xensource.com; 
>> oprofile-list@lists.sourceforge.net
>> Subject: Re: [Xen-devel] xenoprof support patch issue for 
>> oprofile 0.9.3
>> 
>> Santos, Jose Renato G wrote:
>> > Will,
>> > 
>> > Thanks for pointing this out.
>> > I will work on a patch to fix this
>> > By the way, it would be nice to have the xenoprof patches 
>> merged into 
>> > Oprofile CVS tree.
>> > John Levon is not happy with the way passive domain 
>> samples are stored 
>> > now and I don''t have the bandwidth (and knowdledge of
user level
>> > Oprofile code) to do the right fixes. This has prevented 
>> the patches 
>> > to be merged. It would be nice if we can find a volunteer 
>> to do the 
>> > right fixes and have the code merged. I would be happy to assist 
>> > anyone who volunteers for the task. What we need is a way of 
>> > separating samples from different domains and change to 
>> the tools to 
>> > understand this new information.
>> > 
>> > Thanks
>> > 
>> > Renato
>> 
>> Hi Renato,
>> 
>> Definitely want to avoid having separate patches to avoid 
>> just this type of problem. Getting patches upstream is the 
>> way to go on that.
>> 
>> Do you have a pointer to the email discussion about the 
>> passive domain sample storage?
  I will forward the email discussion I had with John on a private
  message
>>  Passive means that the domain 
>> is not taking the samples and storing them in the domain, right?
>> 
  Right! This makes profiling guests in kernel and xen mode much 
  simpler than with active domains and avoids the complexities you
  mention below. With passive domains there is no need to run
  oprofile on guests as dom0 process all guest samples.
  The disadvantage is that you cannot assign 
  user level samples to the right binaries in the guest.
>> One of the things that I have noticed on my previous 
>> experiments with the xenoprof is there are quite a few steps 
>> to setup xenoprof. The user has to do setup on each domain. 
>> Ideally it would be nice to be able to just do one setup in 
>> the host domain and then have that information be propagated 
>> to the guest domains. Similarly the analysis would be nice 
>> to get one over all picture of all the domains. Clusters 
>> have a similar issue; one doesn''t want to manage machine 
>> individually. However clusters may have different hardware 
>> for the various nodes in the cluster. With xen the only 
>> difference could be the software.
>> 
  Yes, profiling multiple guests (as active domains) is somewhat
  complex. But, it should not be difficult to have some wrapper scripts
  to coordinate oprofile execution on multiple domains, using
  possibly ssh, hiding the complexities from the user.
 
  Renato
  
>> -Will
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Renato,

I have munged the xenoprof patch to apply cleanly to the user-space oprofile. 
The patch don''t address the larger changes with handling passive
domains. The
new oprofile-0.9.3-2.fc8 rpm built with this patch can be found at:

http://koji.fedoraproject.org/koji/buildinfo?buildID=11990

The xen kernel space will need to change the defines to correctly match. 
DOMAIN_SWITCH_CODE and LAST_CODE have changed to:


+#define DOMAIN_SWITCH_CODE             13
+#define LAST_CODE                      14


-Will

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

Will

Xenoprof patches for oprofile 0.9.3 (to enable passive domain profiling)
are now available at http://xenoprof.sourceforge.net.
A required patch for the kernel is also available at the same location.
I think the kernel patch should NOT be included into the public Xen tree
at this time, as this will break compatibility with oprofile 0.9.2 that
users are currently using. I think it is better to have users wanting to
upgrade to oprofile 0.9.3 to apply an extra patch to the kernel rather
than breaking compatibility for all current users. I think we should
wait until Xen dom0 support gets into mainline linux to do that (or at
least until xenoprof patches are included in an official oprofile
release).

Regards

Renato
 
>> -----Original Message-----
>> From: William Cohen [mailto:wcohen@redhat.com] 
>> Sent: Thursday, July 26, 2007 7:29 AM
>> To: Santos, Jose Renato G
>> Cc: xen-devel@lists.xensource.com; 
>> oprofile-list@lists.sourceforge.net
>> Subject: Re: [Xen-devel] xenoprof support patch issue for 
>> oprofile 0.9.3
>> 
>> Hi Renato,
>> 
>> I have munged the xenoprof patch to apply cleanly to the 
>> user-space oprofile. 
>> The patch don''t address the larger changes with handling 
>> passive domains. The new oprofile-0.9.3-2.fc8 rpm built with 
>> this patch can be found at:
>> 
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=11990
>> 
>> The xen kernel space will need to change the defines to 
>> correctly match. 
>> DOMAIN_SWITCH_CODE and LAST_CODE have changed to:
>> 
>> 
>> +#define DOMAIN_SWITCH_CODE             13
>> +#define LAST_CODE                      14
>> 
>> 
>> -Will
>> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel