From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marco Tizzoni Subject: Re: Re: [Xen-users] About profiling xen Date: Thu, 1 Oct 2009 23:26:05 +0200 Message-ID: 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: quoted-printable Return-path: In-Reply-To: <4AC51C48.40203@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: "Fajar A." , Fasiha Ashraf , xen , xen-users@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Thu, Oct 1, 2009 at 11:16 PM, Jeremy Fitzhardinge wrot= e: > On 10/01/09 14:05, Marco Tizzoni wrote: >>> The clock*event* mechanism is all about setting up timers to raise even= ts. >>> >>> When running paravirtualized, we use Xen-specific versions of both. >>> >> Ok. =A0My problem is granularity. In xen I can't raise events more >> frequently than 1000/s (with timer set to 1000hz). >> Net test softwares such as netperf or hping use setitimer to send >> packet at a fixed rate. On a non-xen box they works fine even =A0with >> 100k packets/sec (i.e. 100k alarms/sec). This can be problematic for >> streaming software and more in general for soft real-time >> applications. >> [...] >> Thanks for your test, I tried and timers work as expected. > > 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. =A0Hm. > > 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. 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. m-