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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel