From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: VCPUOP_set_periodic_timer Date: Fri, 15 Nov 2013 11:56:18 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4656566726271455996==" 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. --===============4656566726271455996== Content-type: multipart/alternative; boundary="B_3467361391_113567718" > 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_3467361391_113567718 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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 two. Just enough time to wake up the CPU, handle the timer interrupt, and wake u= p 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 On 15/11/2013 11:45, "Simon Martin" wrote: > Thanks Keir, > =20 > That sounds quite reasonable. What granularity can I achieve with this? A= ny > idea on the jitter? > =20 > Regards. > =20 > =20 > ------ Original Message ------ > From: "Keir Fraser" > To: "Simon Martin" ; "Andrew Cooper" > > Cc: "xen-devel@lists.xen.org" > Sent: 15/11/2013 08:36:45 > Subject: Re: [Xen-devel] VCPUOP_set_periodic_timer > =20 >> The periodic_timer is really a coarse-grained timer for driving a legacy >> ticker. It is considered low accuracy and low priority =AD for example, it= is >> stopped entirely while a vcpu is descheduled! >>=20 >> You should use VCPUOP_set_singleshot_timer, and call it again at the end= of >> your timer handler to get the desired periodic behaviour. If you have >> multiple timers in your OS you would manage them in your OS and pick the >> nearest deadline to program down to Xen. >>=20 >> -- Keir >>=20 >> On 15/11/2013 11:24, "Simon Martin" wrote: >>=20 >>> Hi Andrew, >>> =20 >>> The operating system I am trying to port to Xen is an industrial servo >>> controller. We are currently running at 125 microsecond servo update ra= te on >>> our bespoke hardware (at the moment MIPS64 and ARM) (hence the 125 >>> microsecond ideal interrupt period). We will be driving EtherCAT servo >>> drives that need to be updated at 500 microseconds (hence at least 500 >>> microsecond interrupt period). If we can achieve this on a single core = ARM11 >>> clocked at 532 MHz, it must be achievable on PC hardware. As I said bef= ore >>> the idea is to dedicate a CPU core to this with all other functions run= ning >>> on the other cores. >>> =20 >>> Luckily we can accept a reasonable amount of jitter on the EtherCAT net= work >>> as we can hand over clock synchronisation to a slave. This gives us a l= ittle >>> leeway. >>> =20 >>> Regards. >>> =20 >>> =20 >>> ------ Original Message ------ >>> From: "Andrew Cooper" >>> To: "Simon Martin" ; "xen-devel@lists.xen.org" >>> >>> Sent: 14/11/2013 18:39:21 >>> Subject: Re: [Xen-devel] VCPUOP_set_periodic_timer >>> =20 >>>> On 14/11/2013 21:18, Simon Martin wrote: >>>>> Hi all, >>>>> =20 >>>>> I need a periodic timer running at ideally at 125 microseconds and at >>>>> least 500 microseconds. I've just found the VCPUOP_set_periodic_timer= , >>>>> however there is a comment saying "periods less than one millisecond = may >>>>> not be supported". >>>>> =20 >>>>> I will be running on an x64 machine. Is this supported? If not, is th= ere >>>>> any alternate means of generating a fast interrupt? >>>>> =20 >>>>> Regards. >>>>=20 >>>> What is the usecase here? 125us is very short indeed. Xen certainly = cant >>>> guarantee anything more accurate than 50us. Unless the affected vcpu = is >>>> running uncontested on the hardware, there is very little chance that = the >>>> vcpu will indeed be woken up again in 125us. >>>>=20 >>>> It sounds as if you are looking for some pseudo realtime system, at wh= ich >>>> point you might want to consider a different scheduler. >>>>=20 >>>> ~Andrew >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >=20 --B_3467361391_113567718 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Re[2]: [Xen-devel] VCPUOP_set_periodic_timer If you have dedicated a core to the vcpu, so you can discount scheduling c= rosstalk, you shouldn’t miss deadlines by more than a microsecond or t= wo. 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 ca= n take out all CPUs for a period: taking a CPU offline for example. You coul= d 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

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

<= FONT SIZE=3D"2">Thanks Keir,
 
That sounds quite reasonable. What granularity can I achieve with this? Any= idea on the jitter?
 
Regards.
 
 
------ 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:36:45
Subject: Re: [Xen-devel] VCPUOP_set_periodic_timer
 
The periodic_timer is really a coarse-gra= ined timer for driving a legacy ticker. It is considered low accuracy and lo= w priority – for example, it is stopped entirely while a vcpu is desch= eduled!

You should use VCPUOP_set_singleshot_timer, and call it again at the end of= your timer handler to get the desired periodic behaviour. If you have multi= ple timers in your OS you would manage them in your OS and pick the nearest = deadline to program down to Xen.

 -- Keir

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

<= FONT SIZE=3D"2">Hi Andrew,
 
The operating system I am trying to port to Xen is an industrial servo cont= roller. We are currently running at 125 microsecond servo update rate on our= bespoke hardware (at the moment MIPS64 and ARM) (hence the 125 microsecond = ideal interrupt period). We will be driving EtherCAT servo drives that need = to be updated at 500 microseconds (hence at least 500 microsecond interrupt = period). If we can achieve this on a single core ARM11 clocked at 532 MHz, i= t must be achievable on PC hardware. As I said before the idea is to dedicat= e a CPU core to this with all other functions running on the other cores.  
Luckily we can accept a reasonable amount of jitter on the EtherCAT network= as we can hand over clock synchronisation to a slave. This gives us a littl= e leeway.
 
Regards.
 
 
------ Original Message ------
From: "Andrew Cooper" <and= rew.cooper3@citrix.com>
To: "Simon Martin" <smartin@mil= liways.cl>; "xen-devel@lists.x= en.org" <xen-devel@lists.xen.o= rg>
Sent: 14/11/2013 18:39:21
Subject: Re: [Xen-devel] VCPUOP_set_periodic_timer
 
On 14/11/2013 21:18, Simon= Martin wrote:
Hi all,
 
I need a periodic timer running at ideally at 125 microseconds and at least= 500 microseconds. I've just found the VCPUOP_set_periodic_timer, however th= ere is a comment saying "periods less than one millisecond may not be s= upported".
 
I will be running on an x64 machine. Is this supported? If not, is there an= y alternate means of generating a fast interrupt?
 
Regards.

What is the usecase here?  125us is very short indeed.  Xen certa= inly cant guarantee anything more accurate than 50us.  Unless the affec= ted vcpu is running uncontested on the hardware, there is very little chance= that the vcpu will indeed be woken up again in 125us.

It sounds as if you are looking for some pseudo realtime system, at which p= oint you might want to consider a different scheduler.

~Andrew


<= SPAN STYLE=3D'font-size:10pt'>____= ___________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel=

--B_3467361391_113567718-- --===============4656566726271455996== 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 --===============4656566726271455996==--