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:36:45 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8595840105096437313==" 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. --===============8595840105096437313== Content-type: multipart/alternative; boundary="B_3467360211_113511916" > 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_3467360211_113511916 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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! 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. -- Keir On 15/11/2013 11:24, "Simon Martin" wrote: > 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 rate= on > our bespoke hardware (at the moment MIPS64 and ARM) (hence the 125 micros= econd > ideal interrupt period). We will be driving EtherCAT servo drives that ne= ed 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 before the idea is to dedica= te a > CPU core to this with all other functions running on the other cores. > =20 > Luckily we can accept a reasonable amount of jitter on the EtherCAT netwo= rk as > we can hand over clock synchronisation to a slave. This gives us a little > 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 l= east >>> 500 microseconds. I've just found the VCPUOP_set_periodic_timer, howeve= r >>> 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 ther= e any >>> alternate means of generating a fast interrupt? >>> =20 >>> Regards. >>=20 >> What is the usecase here? 125us is very short indeed. Xen certainly ca= nt >> guarantee anything more accurate than 50us. Unless the affected vcpu is >> running uncontested on the hardware, there is very little chance that th= e >> vcpu will indeed be woken up again in 125us. >>=20 >> It sounds as if you are looking for some pseudo realtime system, at whic= h >> 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 --B_3467360211_113511916 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Xen-devel] VCPUOP_set_periodic_timer The periodic_timer is really a coarse-grained timer for driving a legacy t= icker. It is considered low accuracy and low priority – for example, i= t is stopped entirely while a vcpu is descheduled!

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_3467360211_113511916-- --===============8595840105096437313== 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 --===============8595840105096437313==--