Re: [Xen-devel] VCPUOP_set_periodic_timer

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On ven, 2013-11-15 at 11:41 +0000, Andrew Cooper wrote:
> On 15/11/13 11:24, Simon Martin wrote: 
> > 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 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 before the idea is to
> > dedicate 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 little leeway.
> >  
> > Regards.
> >  
> 
> You should investigate using the arinc653 scheduler in Xen, which is a
> realtime scheduler, and might be more appropriate for your usecase.
> 
Right, or even SEDF, if only it were functional! :-/

That's another area where we really need to do better. Luckily enough,
we've got Roland, Joshua and Drek (from GVSU and HsH) working on trying
to 'resurrect' the SEDF scheduler.

Coming to Simon's situation, I think that, as it has already been said,
if you can partition the system in such a way that the real-time VM/OS
gets one full core, without any other interference (either via cpupool
or pinning), there is few point in changing scheduler or scheduling
parameters, and that's probably the setup that would guarantee the most
reliable performances.

If that is not the case, you sure should check arinc, which is probably
a rather "static" algorithm, but I'm quite ignorante (sigh) about how it
actually works, so I can't say anything about it (and I see Nathan is on
it already, so you're in good hands :-)).

If you need something more advanced, while waiting for SEDF to be
'restored', you perhaps can check at RT-Xen (Sisu, one of the main
developers, is also in Cc). Basically, with that, you can enable some
SEDF-alike schedulers, with even more complex and advanced
functionalities.

https://sites.google.com/site/realtimexen/

These schedulers allow you to specify, for each vcpu, a period and a
certain amount of cpu time it will get every period (right Sisu?). This
may turn out to be handy in your case, because you then will have the
guarantee that the vcpu will get a chance to run at least once every
<period> time units. At this point coming up with a period that
guarantees the time granularity that you need shouldn't be too hard,
especially is the system is after all pretty simple, as it looks like.

Of course, it remains to be verified whether the scheduling parameters
can tolerate being set at the small values that your workload
requires... But you cannot get along with a RT-ish system without doing
some measurements, right? :-)

Regards,
Dario

> ~Andrew
> 
> 
> > ------ Original Message ------
> > From: "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>
> > To: "Simon Martin" <smartin@xxxxxxxxxxxx>; "xen-devel@xxxxxxxxxxxxx"
> > <xen-devel@xxxxxxxxxxxxx>
> > 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 there is a comment saying
> > > > "periods less than one millisecond may not be supported".
> > > >  
> > > > I will be running on an x64 machine. Is this supported? If not,
> > > > is there any alternate means of generating a fast interrupt?
> > > >  
> > > > Regards.
> > > 
> > > 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.
> > > 
> > > It sounds as if you are looking for some pseudo realtime system,
> > > at which point you might want to consider a different scheduler.
> > > 
> > > ~Andrew
> > > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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