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


Re: [Xen-devel] Re: [Xen-users] About profiling xen

To: Marco Tizzoni <marco.tizzoni@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Xen-users] About profiling xen
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 01 Oct 2009 14:40:44 -0700
Cc: "Fajar A." <fajar@xxxxxxxxx>, Fasiha Ashraf <feehapk@xxxxxxxxxxx>, xen <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 01 Oct 2009 14:41:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <f9611b0f0910011426w4af0b164re00104fb5a66ebd9@xxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <196324.1267.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20090930063747.GG1434@xxxxxxxxxxx> <f9611b0f0909292340o6a53326aobcd87334d7cfaa6b@xxxxxxxxxxxxxx> <f9611b0f0909300045o55e22378xea270e9873471f1d@xxxxxxxxxxxxxx> <f9611b0f0909300206v53577d1cw300ff6092b8ffede@xxxxxxxxxxxxxx> <4AC3E889.6060407@xxxxxxxx> <f9611b0f0910010035m40949fb3o5efe60469b4466b7@xxxxxxxxxxxxxx> <4AC516EC.3050704@xxxxxxxx> <f9611b0f0910011405h416d2372i3a4c7587b84a3fac@xxxxxxxxxxxxxx> <4AC51C48.40203@xxxxxxxx> <f9611b0f0910011426w4af0b164re00104fb5a66ebd9@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3
On 10/01/09 14:26, Marco Tizzoni wrote:
>> OK, good, that takes timers out of the equation.
>> I guess the problem is the rate at which Xen will context switch between
>> two domains.  Hm.
>> Does anything change if you pin your domains to different cpus?
> mmmh, no. I think without a finer timer the problem could not be solved.

Why's that?  You said that the timers "work as expected", which I read
to mean that they will generate sub-millisecond events.  Did I
misunderstand you?

> For my test application, no problem, I'll use a while() loop with
> counters and sched_yeld(),
> but, for real application, it could be a serious issue to deal with.

I don't see why that would be necessary if timers are working properly.


Xen-devel mailing list