| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] xenoprof support patch issue for oprofile 0.9.3
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
>> William Cohen
>> Sent: Friday, July 20, 2007 7:44 AM
>> To: Santos, Jose Renato G
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx;
>> oprofile-list@xxxxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home