Re: VCPUOP_set_periodic_timer

["Simon Martin" <smartin@milliways.cl>]

[-- Attachment #1.1.1: Type: text/plain, Size: 1524 bytes --]

Latency isn't a big problem. Jitter could be. CPU offline shouldn't be a 
problem as the system is simple and static, at power up I create 2 CPU 
pools, one for the realtime machine domU running on a single core, and 
one for dom0 and a Windows machine running on the remaining cores.

Any idea on the timings I can expect? For example, assuming there are no 
CPU contention issues, if I request a 125 microsecond single shot timer 
interrupt, will I get 125 microseconds +/- 5 microseconds (perfectly 
acceptable) or 500 microseconds (because that is the minimum 
granularity) +/- 50 microseconds (totally unacceptable)?


------ Original Message ------
From: "Keir Fraser" <keir.xen@gmail.com>
To: "Simon Martin" <smartin@milliways.cl>; "Andrew Cooper" 
<andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Sent: 15/11/2013 08:56:18
Subject: Re: Re[2]: [Xen-devel] VCPUOP_set_periodic_timer

>If you have dedicated a core to the vcpu, so you can discount 
>scheduling crosstalk, you shouldn’t miss deadlines by more than a 
>microsecond or two. Just enough time to wake up the CPU, handle the 
>timer interrupt, and wake up the vcpu through the scheduler. There are 
>infrequent operations that can take out all CPUs for a period: taking a 
>CPU offline for example. You could avoid doing such things in your 
>setup perhaps. Ultimately you will need to measure and confirm 
>deadline-to-notification latency distribution if it is critical to you.
>
>  -- Keir

[-- Attachment #1.1.2: Type: text/html, Size: 2799 bytes --]

[-- Attachment #1.2: Type: image/png, Size: 685 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel