From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: [Xen-users] About profiling xen Date: Thu, 01 Oct 2009 14:40:44 -0700 Message-ID: <4AC521DC.2020106@goop.org> References: <196324.1267.qm@web94604.mail.in2.yahoo.com> <20090930063747.GG1434@reaktio.net> <4AC3E889.6060407@goop.org> <4AC516EC.3050704@goop.org> <4AC51C48.40203@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Marco Tizzoni Cc: "Fajar A." , Fasiha Ashraf , xen , xen-users@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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. J