[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] SEDF Scheduler-Temporal Isolation



On Wed, Apr 24, 2013 at 2:36 AM, OrÃun YÄldÄz <oorcun.yildiz@xxxxxxxxx> wrote:
>
> Also,we couldn't figure out what is the difference between current SEDF 
> implementation and CBS. In theory, they seem almost same to us; they both 
> have slice(budget) concepts, they both extend task's deadline when their 
> slice is over and they also replenish their slice at that time. If CBS 
> enables temporal isolation, what does prevent SEDF from being temporally 
> isolated?
>
They are very similar... That's why the original idea of the project
was to modify the former (SEDF) the little that is needed to turn it
into the latter (CBS). Where do they differ? As the project
description itself explains, they differ in how vCPU blocking and
unblocking is handled. Quoting the project description:
http://wiki.xen.org/wiki/Xen_Development_Projects#Implement_Temporal_Isolation_and_Multiplocessor_Support_in_the_SEDF_Scheduler

"SEDF deals with events such as a vCPU blocking --in general, stopping
running-- and unblocking --in general, restarting running-- by trying
to special case all the possible situations, resulting in the code
being rather complicated, ugly, inefficient and hard to maintain."

I'd really like that 'special casing' to go away, and CBS is the
simpler and cleaner solution I know of. Also, please, notice that the
effect might be not so evident, but from a temporal isolation
perspective, the current SEDF behavior might lead to either incorrect
or suboptimal results (depending on the specific case). So, again,
yes, you are right, they're not _much_ different, but sometimes small
differences matters. :-)
Also, again, you're right, it's probably not a big deal to implement
that... Which is even better, isn't it. :-)

> In CBS, for each task we have assigned servers and they accomplish bandwidth 
> reservation for them and this results in temporal isolation. In SEDF, vCPUs 
> have slice and period fields upon to their initialization in do_schedule 
> function but how are they managed in the big picture?
>
Exactly,  but _only_ with the change (re)described above. :-)

That being said, allow me to say that there also is another aspect of
the project, much more trickier and also much more important: "It also
lacks proper multiprocessor support, meaning that it does not properly
handle SMP systems, unless vCPU are specifically and statically pinned
by the user. This is a big limitation of the current implementation,
especially since EDF can work well without the need of imposing this
constraint, providing much more flexibility and efficiency in
exploiting the system resources to their most."

Which, considering how easy the first half should be, would have been
interested to consider.

So, did I answer? :-)

Regards,
Dario

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.