[Xen-devel] RE: [PATCH] Xenoprof passive domain support

["Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>]

Renato,
I remade the patch. It has several improvements.
1) Add a lock for preventing more than one LPs of dom0 from accessing to 
passive domain concurrently.
2) Add escape code only at the beginning and end of a bunch of passive domain 
samples, which dom0 handles one time. Originally we added escape code in front 
of every passive domain sample. That's inefficient.
3) Reuse "normal ESCAPE_CODE" of oprofile to add passive domain switch event 
into the CPU buffer.

Thanks,
-Xiaowei

>-----Original Message-----
>From: Santos, Jose Renato G [mailto:joserenato.santos@xxxxxx]
>Sent: 2006年4月29日 9:43
>To: Yang, Xiaowei
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; John Levon; Yoshio Turner; G John
>Janakiraman
>Subject: RE: [PATCH] Xenoprof passive domain support
>
>Xiaowei,
>
>Thanks for the patch.
>I took a first look in the patch and have a few comments.
>
>First, I think there is a concurrency problem that needs to
>fixed. If dom0 has more than one VCPU, then 2 VCPUs can
>access the same passive buffer at the same time. This
>should not be allowed, since the buffer is not
>protected by any lock. We should make sure that any
>passive domain buffer is accessed by one and only one
>dom0 VCPU. A simple approach would be to have only
>VCPU 0 (in dom0) to handle all the passive domain
>samples. However, this may cause an
>imbalance on the speed that oprofile CPU buffers are filled.
>Probably the cpu buffer for VCPU 0 would fill much
>earlier and cause more frequent flushes to the event buffer,
>increasing the overhead.
>I would prefer if we could distribute the passive
>buffers to all VCPUs in dom0. I will think more about
>this during the weekend and make additional comments,
>earlier next week.
>
>Second, I see that you reused most of the code that
>was used in Xen 2.0, when passive domains was supported
>for non SMP guests.
>John Levon (cc'ed on this message) has made some comments
>on that code which I think we should address right now.
>More specifically, he suggested that we change the way
>domain switches are represented in the CPU buffer.
>Please look at his comment below.
>
>I suggest that we address these 2 issues first and
>then I can look more carefully at the rest of the code.
>Please CC John Levon, on you next messages
>
>Thanks
>
>Renato
>
>Old comments by John Levon on passive domain code:
>=============================================================
>I'm uncomfortable with the chosen domain switching encoding. It's pretty
>confusing to follow all the escaping done already, and you're making it more
>complicated. Why can't you use a normal ESCAPE_CODE? I.e. the buffer would have
>
>   EIP         Event
>---------------------------------
>0. ESCAPE_CODE         DOMAIN_SWITCH
>1. domain ID
>2. EIP         Event
>
>Sure, you lose an entry (1) in size but it means simpler code, and less i-cache
>hurt.
>
>Why is the state not persistent until the next escape code? i.e. it's only for
>one sample.
>
>======================================================================

Attachment: xenoprof2.patch
Description: xenoprof2.patch

Attachment: oprofile-0.8.1-2.patch
Description: oprofile-0.8.1-2.patch

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