Re: [Xen-devel] [PATCH v1 1/4] xen: add real time scheduler rt

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Sep 3, 2014 at 5:57 PM, Dario Faggioli
<dario.faggioli@xxxxxxxxxx> wrote:
>> Re the per-vcpu settings, though: Is it really that common for RT
>> domains to want different parameters for different vcpus?
>>
> Whether it's common it is hard to say, but yes, it has to be possible.
>
> For instance, I can put, in an SMP guest, two real-time applications
> with different timing requirements, and pin each one to a different
> (v)cpu (I mean pin *inside* the guest). At this point, I'd like for each
> vcpu to have a set of RT scheduling parameters, at the Xen level, that
> matches the timing requirements of what's running inside.
>
> This may not look so typical in a server/cloud environment, but can
> happen (at least in my experience) in a mobile/embedded env.

But to play devil's advocate for a minute here: couldn't you just put
them in two different single-vcpu VMs then?

>> Are these
>> parameters exposed to the guest in any way, so that it can make more
>> reasonable decisions as to where to run what kinds of workloads?
>>
> Not right now, AFAICS, but forms of 'scheduling paravirtualization', or
> in general this kind of interaction/communication could be very useful
> in real-time virtualization, so we may want to support that in future.
>
> In any case, even without that in place right now, I think different
> parameters for different vcpus is certainly something we want from an RT
> scheduler.

Yeah, the "expose parameters to guests" was just thinking out loud
about what would be useful in the future.  I think possibly allowing a
VM to change its period (while keeping the budget / period ratio the
same) might make sense as well; that way you could have an RT
"appliance" VM that you could just pop onto a system and let it
configure itself, without the user having to do more than give it
basic parameters.

 -George

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