From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: VCPUOP_set_periodic_timer Date: Fri, 15 Nov 2013 13:10:14 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1444022889777413094==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Simon Martin , Andrew Cooper Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1444022889777413094== Content-type: multipart/related; boundary="B_3467365822_113883289" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3467365822_113883289 Content-type: multipart/alternative; boundary="B_3467365822_113886149" --B_3467365822_113886149 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable You=B9ll have to measure to confirm, but if the core is dedicated to your vcp= u then there is no reason there should be 50us jitter. Also there is not much point playing with different schedulers =8B if there are no other vcpus schedulable on the cpu, the scheduler can=B9t have multiple runnable vcpus to choose between. -- Keir On 15/11/2013 12:37, "Simon Martin" wrote: > 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 po= ols, > one for the realtime machine domU running on a single core, and one for d= om0 > and a Windows machine running on the remaining cores. > =20 > 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 inter= rupt, > will I get 125 microseconds +/- 5 microseconds (perfectly acceptable) or = 500 > microseconds (because that is the minimum granularity) +/- 50 microsecond= s > (totally unacceptable)? > =20 > =20 > ------ Original Message ------ > From: "Keir Fraser" > To: "Simon Martin" ; "Andrew Cooper" > > Cc: "xen-devel@lists.xen.org" > Sent: 15/11/2013 08:56:18 > Subject: Re: Re[2]: [Xen-devel] VCPUOP_set_periodic_timer > =20 >> If you have dedicated a core to the vcpu, so you can discount scheduling >> crosstalk, you shouldn=B9t miss deadlines by more than a microsecond or tw= o. >> Just enough time to wake up the CPU, handle the timer interrupt, and wak= e 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 a= void >> doing such things in your setup perhaps. Ultimately you will need to me= asure >> and confirm deadline-to-notification latency distribution if it is criti= cal >> to you.=20 >>=20 >> -- Keir >=20 --B_3467365822_113886149 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Re[4]: [Xen-devel] VCPUOP_set_periodic_timer You’ll have to measure to confirm, but if the core is dedicated to y= our vcpu then there is no reason there should be 50us jitter. Also there is = not much point playing with different schedulers — if there are no oth= er vcpus schedulable on the cpu, the scheduler can’t have multiple run= nable vcpus to choose between.

 -- Keir

On 15/11/2013 12:37, "Simon Martin" <smartin@milliways.cl> wrote:

<= FONT SIZE=3D"2">Latency isn't a big problem. Jitt= er 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 CP= U contention issues, if I request a 125 microsecond single shot timer interr= upt, will I get 125 microseconds +/- 5 microseconds (perfectly acceptable) o= r 500 microseconds (because that is the minimum granularity) +/- 50 microsec= onds (totally unacceptable)?
 
 
------ Original Message ------
From: "Keir Fraser" <keir.xen@gma= il.com>
To: "Simon Martin" <smartin@mil= liways.cl>; "Andrew Cooper" <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xen.org&quo= t; <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 deadline= s by more than a microsecond or two. Just enough time to wake up the CPU, ha= ndle 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 per= haps. Ultimately you will need to meas= ure and confirm deadline-to-notification latency distribution if it is criti= cal to you.

 -- Keir
=
--B_3467365822_113886149-- --B_3467365822_113883289 Content-Type: image/png; name="image.png" Content-ID: <3467365814_113877269> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAJXSURBVDhPnZBPSJNxGMefQ5d2SDpUdCkIVl26tIiKUsOgWLEO6WHuUAgt oogORVDZIQwkCLpIvEqZSvjiIZcQSb3OmZvCHCKLoQ7McKi1rXzpH72v2/v0fH9bq4OnBt99 3+f5fp7vCy8tdBNleoiWe4k+6uTK9pFPpIkMUbzsmH3IwYHHHTOXHsoFbpH+Jbxv1vpw1yzm u2z++tyBY8YeObi1CtyL+vqhH6kLOc5rzFlRros531NyzLJHDg58pWDuMbnmO0n/ngzklkb8 /KZ1h9Ji9BI7y4+U/9khBwced6og3U6+xYHdaef9RV4yvJx5fZozRj0vRwLszDcrx4w9cnDg cacKUm2kfZusN4tTp9gcPc6FgsWeoMZm7AwXU+eUY8YeOTjwuFMFUw/JsN757UK8jlfCRxQY 1BK8MlzHhcRJ5ZixV7lw4HGnCuL3KV5INjirsWouqZZXx6Cj/0hm7MsMeNypgmgLGT/HvbY9 coinn+5k++1hUTXbozWi2pJjlv10l+TCgcedKjBuk/bp5UHTGjrA/Tc3sH69il+1bKt8eWjw 3nbuu7GR+29VMTjwuFMFoavki7ZuTlvDNZwN7edQ8yaeScYk+/vDPHBni8rBgcedRETPzpOr u4n0mSd7clbkBOcHvTyh7eXIg13q7fBEu4c/yx45OPC4UwUdAaL2RnJ3nl03lOrw5KyxANsT QbYnL4uulFxm7JGDA4+7SoHmJ2prILdIf3Ft6+xc7zHTDDfav8abHDhm7JGDA79WAeQS+USa yBDFy44Ze+SKrxTg7//F9Bs8U4bjEi0nagAAAABJRU5ErkJggg== --B_3467365822_113883289-- --===============1444022889777413094== 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.xen.org http://lists.xen.org/xen-devel --===============1444022889777413094==--