|
xen-devel
RE: [Xen-devel] RE: [PATCH] Xenoprof passive domain support fixes
Ray,
Please, see my comments below.
>> -----Original Message-----
>> From: Ray Bryant [mailto:raybry@xxxxxxxxxxxxxxxxx]
>> Sent: Tuesday, July 11, 2006 12:02 PM
>> To: xen-devel@xxxxxxxxxxxxxxxxxxx
>> Cc: Santos, Jose Renato G; Yang, Xiaowei
>> Subject: Re: [Xen-devel] RE: [PATCH] Xenoprof passive domain
>> support fixes
>>
>> Renato,
>>
>> One thing I am still puzzled by in all of this is the
>> following: In the "opreport -x" output, I get entries for
>> both pxen*-syms (which is a symbolic link to the xen-syms I
>> supplied on the opreport command line) AND I get entries for
>> xen-syms itself:
>>
>> samples| %|
>> ------------------
>> 76273 23.7270 papps2-syms
>> 73306 22.8040 pxen2-syms
>> 63550 19.7691 vmlinux
>> 43024 13.3839 libc-2.4.so
>> 24406 7.5922 xen-syms
>> 17278 5.3748 jbd
>> 12228 3.8039 ext3
>> 9845 3.0626 oprofiled
>> 395 0.1229 qemu-dm
>> <snip>
>>
>> Why is that? (I've been told the xen-syms samples are
>> samples in the hypervisor due to dom0 activity, but I've
>> been unable to verify this).
>>
Yes, that is correct. Every sample (including the ones in the
hypervisor)are associated with a domain ( the current domain running on
the CPU as indicated by the Xen macro "current"). Therefore opreport
distinguish hypervisor samples based on the domain that was running at
the time the sample was generated.
>> Additionally, I find that "opreport -lx" will report "no symbols" for
>> papps*-syms:
>>
>> samples % app name symbol name
>> 76273 23.7738 papps2-syms (no symbols)
>> 19131 5.9630 pxen2-syms l2e_rw_fault
>> 17278 5.3854 jbd (no symbols)
>> 12228 3.8114 ext3 (no symbols)
>> 11840 3.6905 libc-2.4.so vfprintf
>> 10256 3.1967 libc-2.4.so
>> _IO_file_xsputn@@GLIBC_2.2.5
>> 8587 2.6765 xen-syms general_protection
>> 7374 2.2984 pxen2-syms vmx_asm_vmexit_handler
>> 5212 1.6245 pxen2-syms resync_all
>> 5128 1.5984 xen-syms write_cr3
>> <snip>
>>
>> unless I do an "ln -s /boot/vmlinux2-syms
>> /boot/papps2-syms". (It appears that opreport should be
>> creating papps2-syms instead of vmlinux2-syms??)
>>
papps2-syms represent samples collected in user level for domain2 (i.e.
ring 3). Remember that passive domain profiling cannot decode
application level samples since domain0 does not know the current memory
mappings of user level processes in domain 2. Therefore it is expected
that opreport will report "no symbols" for papps2-syms.
What is suspicious to me is that opreport is not reporting any samples
in the kernel for domain2 (they should have appeared under the name
vmlinux2-syms)
This is probably a bug. Maybe this is triggered if you do not specify
the option --passive-images. Did you specify this option? If not, try
running the command with --passive-images=<linux image file for xenU>
(e.g. --passive-images=/boot/vmlinux-syms-2.6.16-xenU)
>> Finally, I'm not convinced yet that the sample reports for
>> the HVM guest (papps2-syms or pvmlinux2-syms, in this case)
>> are correct. I'm going to run some native and xen profile
>> sessions using the same benchmark and see if I can correlate
>> the results at all.
>>
There is a problem with the current version of xenoprof for passive
domains. Samples are being assigned to wrong samples. I posted a patch
last week, that fix this problem but it seems that it was not pushed
into the main unstable tree yet.
Try applying that patch and check if they match what you get from
native.
(If you cannot find the patch, please let me know I will forward it to
you)
I would appreciate if you could send me the results of your tests,
either if you find problems or if they are successfull. I think not many
people have used passive domain support yet, and any feedback would be
usefull.
Thanks
Renato
>> --
>> Ray Bryant
>> AMD Performance Labs Austin, Tx
>> 512-602-0038 (o) 512-507-7807 (c)
>>
>>
>>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home