Xen devel - Oct 2011 - [Project Idea]:-Want a guidance for the project

Respected Sir,
                     I am an undergraduate student from Pune
University(India).As my last year project we are thinking of implementing
the co-scheduling in Xen for concurrent jobs depending on the degree of
concurrency of the domain.
      Sir, abstract for my project is as:

Abstract---Symmetric multiprocessing (SMP) virtual machine (VMs) allow user
to take advantage of multiprocessor architecture. Xen current scheduler
schedules the virtual CPUs (vCPUs) of a virtual machine asynchronously,
which guarantees the proportion of CPU time corresponding to its weight,
maximizing the throughput of the system. But the performance may
deteriorated while executing concurrent applications due to current
scheduling strategy. To address this problem Yulong Yu et al. proposed
co-scheduling strategy in which vCPUs of a SMP VM are scheduled
simultaneously. But this approach causes other problems such as CPU
fragmentation, priority inversion that degrades I/O performance. Our
implementation is inspired from the work proposed by Orathai Sukwong et al.
in Kernel Virtual Machine (KVM) where no two vCPUs are forced to schedule
simultaneously though they are executing concurrent jobs. Our implementation
tries to co-schedule concurrent vCPUs depending on the degree of
co-scheduling of a domain. If degree of co-scheduling of a VM is less than
some threshold value then vCPUs of a VM are scheduled asynchronously and if
it is more then all vCPUs are forced to scheduled simultaneously.

Keywords: Symmetric multiprocessing virtual machine, Xen, Co-scheduling,
KVM, Balance Scheduling

       Forceful co-scheduling of VM may cause many problems such as CPU
fragmentation,priority inversion..This scheduling strategy may keep a
balance.

Sir can you suggest any improvement to this idea.Should I mail you our
project synopsis?

Thanking you


**

* *


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

On Thu, Oct 6, 2011 at 3:38 PM, Pratik shinde <pracshi@gmail.com>
wrote:
> Respected Sir,
>                      I am an undergraduate student from Pune
> University(India).As my last year project we are thinking of implementing
> the co-scheduling in Xen for concurrent jobs depending on the degree of
> concurrency of the domain.
>       Sir, abstract for my project is as:
>
> Abstract---Symmetric multiprocessing (SMP) virtual machine (VMs) allow user
> to take advantage of multiprocessor architecture. Xen current scheduler
> schedules the virtual CPUs (vCPUs) of a virtual machine asynchronously,
> which guarantees the proportion of CPU time corresponding to its weight,
> maximizing the throughput of the system. But the performance may
> deteriorated while executing concurrent applications due to current
> scheduling strategy. To address this problem Yulong Yu et al. proposed
> co-scheduling strategy in which vCPUs of a SMP VM are scheduled
> simultaneously. But this approach causes other problems such as CPU
> fragmentation, priority inversion that degrades I/O performance. Our
> implementation is inspired from the work proposed by Orathai Sukwong et al.
> in Kernel Virtual Machine (KVM) where no two vCPUs are forced to schedule
> simultaneously though they are executing concurrent jobs. Our
implementation
> tries to co-schedule concurrent vCPUs depending on the degree of
> co-scheduling of a domain. If degree of co-scheduling of a VM is less than
> some threshold value then vCPUs of a VM are scheduled asynchronously and if
> it is more then all vCPUs are forced to scheduled simultaneously.
>
> Keywords: Symmetric multiprocessing virtual machine, Xen, Co-scheduling,
> KVM, Balance Scheduling
>
>        Forceful co-scheduling of VM may cause many problems such as CPU
> fragmentation,priority inversion..This scheduling strategy may keep a
> balance.
>
> Sir can you suggest any improvement to this idea.Should I mail you our
> project synopsis?
Just be aware, that schedulers are very difficult to write and modify.
 To write a gang scheduler such as you describe is a very ambitious
project.

 -George

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

Respected Sir,
      Sir I just want to ask you few questions:

   1.  If this is too big project then can you suggest any subset of this
   idea which can be implemented in four months by the team of four
   undergraduates?
   2. Sir, if we just implement gang scheduler rather than depending on the
   degree of co-scheduling,whether that would be a good project?
   3. Can I CC you from above if I face some problems in project work?

Thanking you,
Pratik Shinde


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

On Thu, Oct 6, 2011 at 4:16 PM, Pratik shinde <pracshi@gmail.com>
wrote:
> Respected Sir,
>       Sir I just want to ask you few questions:
"Respected Sir" is a little over-the-top for open-source culture,
which is a bit more laid back.  :-)  A more appropriate thing to say
here would be something like, "Thank you for your time."
>  If this is too big project then can you suggest any subset of this idea
> which can be implemented in four months by the team of four undergraduates?
I''m sorry, that''s not my job. :-)
> Sir, if we just implement gang scheduler rather than depending on the
degree
> of co-scheduling,whether that would be a good project?
Whether it''s possible for a team of four undergraduates depends on the
undergraduates.  I''m just warning you that schedulers are harder than
they look.  They''re a minefield of deadlocks and race conditions, and
you''ll be on your own in debugging them.

Whether it will meet the requirements is something only your professor
can answer.
> Can I CC you from above if I face some problems in project work?
I''m afraid you can''t expect too much help from us, especially
in the
difficult questions about algorithms, deadlocks, and race conditions.
So consider this before committing to this project.

If you decide to go ahead, "printk" and a serial console is your
friend:
 http://wiki.xen.org/xenwiki/XenSerialConsole

 -George

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

Although is a challenging project and would be very interesting to do, if we
decide to go ahead with it,
I''m concerned about just one other thing, i.e. does this have a strong
use-case?
As in, how much would this benefit the users of Xen, if they could have a
co-scheduler?


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

On Thu, 2011-10-06 at 17:11 +0100, Pratik shinde wrote:
> Although is a challenging project and would be very interesting to do,
> if we decide to go ahead with it, 
> I''m concerned about just one other thing, i.e. does this have a
strong
> use-case?
> As in, how much would this benefit the users of Xen, if they could
> have a co-scheduler? 
First of all, in the Xen community, "co-scheduling" has a different
meaning: it has to do with making the scheduler aware of the
relationship between a VM and its stubdomain, driver domain, or other
service domains.  So you should probably come up with a different term
for what you''re trying to do.

Secondly, if you''re thinkinking about getting your code into the
mainline Xen tree, there are two options: you could try to get gang
scheduling into the default scheduler, or you could try getting an
alternate scheduler added.  The bar for both would be pretty high.

Regarding getting gang scheduling into the default scheduler: Most of
the Xen developers think that gang scheduling isn''t the right solution
to the problem, and that paravirtualization of guest synchronization
primitives is the right solution.  So to get changes made to the default
Xen scheduler, you''d have to make a convincing argument (including
extensive testing of multiple workloads) that gang scheduling would be
an improvement over the current situation.

Regarding getting in an alternate scheduler: You''d need to convince the
community that (1) there are a reasonable number of users who would want
to use it, and (2) that you are able and willing to maintain it going
forward.  If you were a company, that would not be difficult (see the
arinc scheduler, for example).  But since you are students, you
currently don''t have any users, and most likely you will disappear
after
your project is done.  Disappearing after your project is done is a
perfectly reasonable thing to do, but it does leave the community stuck
trying to support your code.

Gang scheduling would certainly teach you a lot about OSes and
scheduling, and so I''m sure it''s a valuable learning tool.

If you want some other ideas for undergraduate-level projects, you might
look at the recent Google Summer-of-code suggestions, which can be found
here:
 http://wiki.xen.org/xenwiki/GSoC_2011_ideas

These are projects that are definitely valuable to the community.  How
much help you get will depend mostly on how likely we think you are to
be able to succeed. 

 -George


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

Think you for your time,
          As gang scheduler would an interesting tool to learn about
operating systems, and as we are students we want to learn more about O.S.So,we
all decided to go with our idea to implement the gang scheduler. Thank you
for your kind guidance and your help.
Thankig you,


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