Re: [Xen-devel] co-scheduler modification

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Sun, Jul 8, 2012 at 2:47 PM, Kerti Csaba <csocskos@xxxxxxxxxxx> wrote:
> Hi Dear Forum!
>
>
> In my experience I need to modify a bit the Xen Scheduler. I need to
> implement a type of co-scheduling algorithm, which is try to schedule those
> VMs (on physical machines) together which are communicating together. This
> solution should avoid that situation when the communication of VMs are
> actives at differnet times which is slows down the communication.
>
>
> In the first round I was thinking to implement a simple algorithm which is
> only boost the priority that VM which is receive a message.
>
>
> I still haven’t decided that which scheduler will I modify(SEDF or Credit).
>
>
> I started to examine the source code of the scheduler. As far as I see there
> is no similar solution in schedule.c or in sched_credit.c and sched_sedf.c
> that if  the actual VM received a message or not, or to boost the priority
> in case of message receiving VM.

FYI, the credit scheduler will already boost the priority of a VM when:
1. It hasn't used all of its credits
2. It has yielded the cpu
3. It receives an interrupt or event channel.

So under certain conditions, a VM will already be boosted when it
receives a message.

The challenge with scheduling isn't necessarily to make your
particular workload work well; it's to make sure that:
1) All the competing workloads still work well
2) No one can take advantage of your scheduler to get more than their
"fair share'.

For instance, can two vcpus completely monopolize the processor by
simply sending each other messages?

In my experience, what often works better is to do the opposite of
what you'd expect: by choosing *not* to run a VM now, that means that
its credit will build up and it will be higher priority later.  So for
example, if VM A is communicating with VM B, and VM B doesn't have
enough priority to run right now, have VM A wait until VM B does have
enough credit to run; then run them both together.

Does that make sense?

 -George

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