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

Re: [Xen-devel] VCPUOP_set_periodic_timer

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.
This is the configuration I am working on. The system is reasonably simple, a single flat memory space with it's own simple scheduler, so I can't see why it shouldn't work, as long as I can get the granularity out of the underlying system.
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 :-)).
In this kind of environment, a static algorithm is good. It is much better to be predictable than flexible. In an industrial setting where this is controlling machinery that can potentially kill the operators the principle of least surprise is what you need.
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
Before I embarked on this I looked at RealTime Xen. Very interesting project, however from my understanding of the Xen architecture I thought that the vanilla Xen would be sufficient. This is still my fallback position.
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? :-)
This is what is missing. There is a steep learning curve on how to write a PV guest. The mini-os is a good starting point, and so is David Chisnall's book, however in many ways the mini-os is overkill for what I want as a proof of concept where I want to do the bare minimum to interface with Xen and just work on the fixed flat memory space that it initialises with.
Once I have this working smoothly I'll look at timings, however I really needed to know whether what I am asking is feasible or not. From all the answers I think that it is more than feasible, not only due to the Xen infrastructure, but also because of the good will of the people involved.
Thanks very much.

PNG image

Xen-devel mailing list



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