[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] VCPUOP_set_periodic_timer

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.