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 13:54:04 -0700 Message-ID: <4AC516EC.3050704@goop.org> References: <196324.1267.qm@web94604.mail.in2.yahoo.com> <20090930063747.GG1434@reaktio.net> <4AC3E889.6060407@goop.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------000102020809080000060407" 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 This is a multi-part message in MIME format. --------------000102020809080000060407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/01/09 00:35, Marco Tizzoni wrote: > On Thu, Oct 1, 2009 at 1:23 AM, Jeremy Fitzhardinge wrote: > >> Your clocksource is "xen", which is the best possible for a PV xen guest. >> >> However, a clocksource is for measuring elapsed time, not triggering >> timers. >> > Why? How would you solve the problem of raising events at a fixed rate? > I'm not sure I follow you. In the kernel, the clock*source* subsystem is for measuring time: its used to implement gettimeofday, as well as internal time accounting. It isn't directly related to time events. The clock*event* mechanism is all about setting up timers to raise events. When running paravirtualized, we use Xen-specific versions of both. >> Unfortunately there doesn't seem to be a /sys file to show the >> current clockevent source in use, but if you have "xen" clocksource it's >> almost certainly the xen clockevent. >> >> However, this is only relevent if you have CONFIG_NO_HZ and >> CONFIG_HIGHRES_TIMERS enabled. >> > I've tried both set/unset but nothing change. > Hm. Its best to leave both enabled either way. Try the attached program to get some info about how well timers are working. Compile with: $ gcc -o testtimer testtimer.c -O -lrt And test various results: $ ./testtimer .1 > xen-0.1.out $ ./testtimer .01 > xen-0.01.out $ ./testtimer .001 > xen-0.001.out You can plot the results with: $ gnuplot gnuplot> plot "xen-0.001.out" with lines The plot is delta from the expected time, so the ideal is that they all be 0. On my system in dom0 I see about 10% overhead at .001 and .0005 sec, so the timers aren't being quantized to 100/250Hz. J --------------000102020809080000060407 Content-Type: text/x-csrc; name="testtimer.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="testtimer.c" #include #include #include #include #define SAMPLES 1000 static double samples[SAMPLES]; static const char prog[] = "/-\\|"; #define NS 1000000000 int main(int argc, char **argv) { int i, iter; struct timespec start, end; struct timespec sleep; double base; if (argc < 2) base = .1; else base = strtod(argv[1], NULL); iter = 20 / base; if (iter > SAMPLES) iter = SAMPLES; fprintf(stderr, "%d iterations at %f sec\n", iter, base); sleep.tv_sec = 0; sleep.tv_nsec = base * NS; while (sleep.tv_nsec >= NS) { sleep.tv_sec++; sleep.tv_nsec -= NS; } for(i = 0; i < iter; i++) { double delta; fprintf(stderr, "%c\b", prog[i % (sizeof(prog)-1)]); clock_gettime(CLOCK_MONOTONIC, &start); nanosleep(&sleep, NULL); clock_gettime(CLOCK_MONOTONIC, &end); delta = (end.tv_sec * NS + end.tv_nsec) - (start.tv_sec * NS + start.tv_nsec); samples[i] = delta - (base * NS); } for(i = 0; i < iter; i++) printf("%f\n", samples[i] / NS); return 0; } --------------000102020809080000060407 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------000102020809080000060407--