co-scheduler modification

co-scheduler modification

[Kerti Csaba]

[-- Attachment #1.1: Type: text/plain, Size: 1401 bytes --]


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.


My idea is
that I need gain information from the code of event channel (event_channel.c)
or Reception-I/O ring and create a new function for the schedulers which boost
the priority of the receiving VM. 
But I don’t know which function can appropriate
in event_channel.c to get this information, and maybe this idea is not good at
all.


How can I
gain this information and how can I activate or boost the priority of the receiving
VM ?


I would be
happy for any idea!


Thank you

Csaba 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 2775 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: co-scheduler modification

[George Dunlap]

On Sun, Jul 8, 2012 at 2:47 PM, Kerti Csaba <csocskos@hotmail.com> 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

Re: co-scheduler modification

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1346 bytes --]

On Sun, 2012-07-08 at 15:47 +0200, Kerti Csaba wrote: 
> 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. 
>
Sounds very reasonable in principle, but do expect to deal with weird
situation and to consider counterintuitive solutions to them, as George
already stated.

> I still haven’t decided that which scheduler will I modify(SEDF or
> Credit).
> 
Just wanted to add that sedf _should_ be easy enough to understand and
modify for this purpose, and it does not do anything like that yet (as
opposed to credit), at least when it wears its "pure real-time" shoes.

Unfortunately, it's not in such a good shape, e.g., it has a very poor
SMP support, which would need make the life of people wontting to work
with it harder that it should be.

Not that this should prevent you to look at it... I just wanted to be
sure you're aware want you'll find there. :-)

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



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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