[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: [PATCH] Xenoprof passive domain support
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 Attachment:
oprofile-0.8.1-2.patch _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |