Re: [Xen-devel] VCPUOP_set_periodic_timer

["Simon Martin" <smartin@xxxxxxxxxxxx>]

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@xxxxxxxxx>

To: "Simon Martin" <smartin@xxxxxxxxxxxx>; "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>

Cc: "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>

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

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