WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ti

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ticks
From: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Date: Fri, 02 Nov 2007 11:51:14 -0400
Cc: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Shan, Haitao" <haitao.shan@xxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Delivery-date: Mon, 19 Nov 2007 10:15:29 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C350A115.17D26%Keir.Fraser@xxxxxxxxxxxx>
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>
References: <C350A115.17D26%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
Keir,

I agree with removing the check.

Sorry, I was a bit vague with the rounding term.

My experiments show that delivering clock interrupts
in a constant N*period time space results in a .4% improvement
in accuracy over delivering interrupts at context switch (in) time
and resetting the N*period time space.
Lets call the former technique method S (synch) and the later AS
(async).

Now I will offer an explanation without proof.
If you would like proof, I can instrument the hypervisor to see
if this explanation is correct.

Let D be the time that the clock vcpu is descheduled and P be
the clock period.  When D < P, I think there is an issue.

The reason is that Linux's offset calculation, which affects the
last clock interrupt tsc that is recorded, doesn't kick in if the
time since the last interrupt is less than P. In this case it sets
offset to zero. Linux records the tsc of the current (last) clock interrupt
as (current tsc - offset).

Interrupt delivery method AS delivers a clock interrupt
at context switch (in) time. When D < P, Linux records the
interrupt delivery time as current tsc and bumps jiffies.
This results in a gain of time equal to P-D over wall time.

For method S this never happens because the interrupt isn't
delivered until the next boundary.

regards,
Dave




Keir Fraser wrote:

On 1/11/07 21:14, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx> wrote:

1. Increase missed ticks threshold to 100 seconds. Per the comment in
the patch,

I assume that's the magic number 100000 in the patch? I think removing the
check entirely would be better than an arbitrarily high threshold that we're
baiscally hoping will never trigger.
3.  Call pt_process_missed_ticks() unconditionally and place the
   test for no_missed_tick_accounting inside pt_process_missed_ticks().
   This returns the calculation for the next timer expiration
   to the original method. The original method is important
   as it sets up a theoretical time space at t=0 where expirations
   occur only at n*period, where n is any integer. This, in turn, removes
   rounding errors.

Why do 'rounding errors' matter? I thought that no_missed_tick_accounting
was for guests which sampled the TSC on tick interrupt and used that to
determine elapsed wall time, in which case why would it matter when exactly
the tick interrupt is delivered?


-- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel