Re: [Xen-devel] [RFC PATCH 3/4] Updated comments/variables to reflect cbs, fixed formatting and confusing comments/variables

[Meng Xu <xumengpanda@xxxxxxxxx>]

Hi Dario,

[Adding RT-Xen people to the discussion, as well as Lars and Andrii from
GlobalLogic]

âThank you very much for adding us to the discussion! :-)â

Related to this, there are basically two groups of people working on
real-time scheduling:

Â1) Josh and Robbie @ Dornerworks (+ Nate), working on fixing SEDF;

Â2) RT-Xen developers, working at isolating the upstreamable bits of
  RT-Xen itself (although they've not sent patches here in public
  yet).

The very nice part of 1) is that it (in the long run) fixes SEDF, and if
we are to keep it in the tree, I really think it should be fixed!

The very nice part of 2) is that it is already a more advanced and
mature real-time scheduling solution (for example, it already deals with
SMPs correctly, unlike current SEDF and Josh's RFC), but it really does
not have much to do with SEDF (either broken or fixed), both at an
interface and implementation (i.e., code sharing) points of view either.

âRight now, our scheduler (we call it rtglobal, but the name can be changed to SEDF easily) supports the following functions:

1) global EDF schedulingâ based on each VCPU's deadline;

2) set/get *each* VCPU's parameter of each domain scheduled by the real time scheduler;

3) supports cpupool.

Here is a simple scenario to show the above functions of our scheduler:

//list each vcpu's parameters of each domain in cpu pools using rtglobal scheduler

â#xl sched-rtglobal

Cpupool Pool-0: sched=EDF

Name                ÂID Period Budget Vcpu

Domain-0 Â Â Â Â Â Â Â Â Â Â Â Â Â Â 0 Â Â 10 Â Â 10 Â Â0

Domain-0 Â Â Â Â Â Â Â Â Â Â Â Â Â Â 0 Â Â 20 Â Â 20 Â Â1

Domain-0 Â Â Â Â Â Â Â Â Â Â Â Â Â Â 0 Â Â 30 Â Â 15 Â Â2

Domain-0 Â Â Â Â Â Â Â Â Â Â Â Â Â Â 0 Â Â 10 Â Â 10 Â Â3

litmus1 Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â1 Â Â 10 Â Â Â4 Â Â0

litmus1 Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â1 Â Â 10 Â Â Â7 Â Â1

//set domain litmus1's vcpu 1's parameters:â

#Âxl sched-rtglobal -d litmus1 -v 1 -p 20 -b 10

â//domain litmus1's vcpu 1's parameters are changed, display each VCPU's parameters separately:â

#âxl sched-rtglobal -d litmus1

Name                ÂID Period Budget Vcpu

litmus1 Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â1 Â Â 10 Â Â Â4 Â Â0

litmus1 Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â1 Â Â 20 Â Â 10 Â Â1

ââ//list cpupool's information (cpupool test has credit scheduler and has a domain litmus2 already)

â#xl cpupool-list -c

Name        CPU list

Pool-0 Â Â Â Â Â Â 0,1,2,3,4,5,6,7

test        10,11

//migrate litmus1 from cpupool Pool-0 to cpupool test.

#xl cpupool-migrate litmus1 test

â//now litmus1 is in cpupool test

#âÂxl sched-credit

Cpupool test: tslice=30ms ratelimit=1000us

Name                ÂID Weight ÂCap

litmus1 Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â1 Â Â256 Â Â0

litmus2 Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â2 Â Â256 Â Â0

By reading the mailing list, I think Josh is working on modifying SEDF to achieve 1) and 2). (Correct me if I'm wrong. :-) ) So I'm thinking if we can just merge code from both sides to simply get a better SEDF instead of doing duplicate work in both sides?Â

âI compared our rtglobal scheduler with the simplified SEDF Josh and Nate are proposing, the only difference with these two algorithms is the budget replenish mechanism we are using: Josh and Nate will use the Constrant Bandwidth Server mechanism but we used the Deferrable Server mechanism. Both of these two server mechanisms are proved to be workable for real-time applications and we actually can supports both later without affecting user interface.Â

So, again, depending on whether or not we want to keep SEDF, and how
hard we want for it's interface not only to compile, but to remain
meaningful, the way forward changes. That's why I'm asking what we want
to do with SEDF. :-/


Assuming that we *do* want to keep it, my personally preferred way to
proceed would be:
Â- we take the implementation changes, but not the renaming, from Josh's
 Âeffort
Â- we merge the sched_sedf.c resulting from above with sched_rtglobal.c
 Âfrom RT-Xen, so to have a solution that works well on SMP systems
 Âand also implements the existing SEDF interface

The merge can happen 'either way', i.e., we can try to borrow the global
scheduling bits (i.e., the SMP support) from RT-Xen's sched_rtglobal.c
into sched_sedf.c or, vice-versa, import Josh's SEDF/CBS code inside
sched_rtglobal.c... In either case, I'd need Josh and Meng, and their
respective fellows, to collaborate... Are you guys up for that? :-)

âI totally agree with you, Dario! I'd like to collaborate with Josh to get a better real-time scheduler in Xen. :-)â

âThanks,

Mengâ

-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

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