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.
>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
>Subject: RE: [PATCH] Xenoprof passive domain support
>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
>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
>Why is the state not persistent until the next escape code? i.e. it's only for
Xen-devel mailing list