This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] RE: Passive domain support in Xenoprof 2.0

To: "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>
Subject: [Xen-devel] RE: Passive domain support in Xenoprof 2.0
From: "Santos, Jose Renato G" <joserenato.santos@xxxxxx>
Date: Thu, 9 Feb 2006 11:58:27 -0800
Cc: "Turner, Yoshio" <yoshio_turner@xxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, G John Janakiraman <john@xxxxxxxxxxxxxxxxxxx>, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Delivery-date: Thu, 09 Feb 2006 20:09:45 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYtVUSI4uKFLHhbRb6jkPFljCru3gATi9sA
Thread-topic: Passive domain support in Xenoprof 2.0

  The passive domain support implementation for Xen 2.0 had
  some race conditions and that was the reason it was removed
  from the patches for the Xen 3.0 implementation. The buffers
  that are used to store PC samples do not use any
  locks since they need to be accessed in NMI context.
  In the previous implementation, samples of passive domains
  were stored in dom0's buffer. This created the possibility
  of a race condition if dom0 and a passive domain were
  running on 2 different CPUs and accessing the buffer

  Adding support for passive domains in Xen 3.0 is on
  my todo list, but I am not sure how long it will take until
  I have time for working on it. If you have urgency you
  may want to work on this yourself.
  I will be happy to review any patches that you might create.
  If you decide to work on this you will have to use approach 2.
  Approach 1 would have the same race condition issues of
  the previous xenoprof implementation.
  Basically, we need to use one buffer for each VCPU of
  domains being profiled (including active and passive domains).
  Dom0 would then have to read samples from all passive domain
  buffers (in addition to its own buffers) and copy them
  to correspondent oprofile CPU buffers (also one per
  VCPU, matching xen buffers 1 to 1). Then we would need
  to change oprofile kernel module (in dom0) to also read samples
  from the passive domain CPU buffers when
  combining them into the oprofile event buffer.




>> -----Original Message-----
>> From: Yang, Xiaowei [mailto:xiaowei.yang@xxxxxxxxx] 
>> Sent: Thursday, February 09, 2006 12:46 AM
>> To: Santos, Jose Renato G
>> Cc: Dong, Eddie; Zhai, Edwin; xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: Passive domain support in Xenoprof 2.0
>> Hi Renato,
>> I'd like to talk with you about Xenoprof. 2 obvious changes 
>> in Xenoprof 2.0 is
>> 1) alloc/handle buffer per vcpu 
>> 2) remove passive damain machenism 
>> I'm not sure why you remove passive domain (for clear 
>> implemetation?), but it's essential for tuning VMX domain. 
>> Since buffer allocation is changed, for now I can think of 2 
>> ways to handle passive domain samples:
>> 1) add passive samples in primary domain's buffer and let it 
>> handle it in Xenoprof 1.1 way, or
>> 2) alloc another dedicated buffer for passive domains and 
>> let primary domain do extra work to handle it. After that, 
>> our enhancement to map passive domain samples to 
>> xen/kernel/application can work again. 
>> What do you think of it?
>> -Xiaowei

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>