Re: [Xen-devel] [PATCH v2] Modified RTDS scheduler to use an event-driven model instead of polling.

[Dagaen Golomb <dgolomb@xxxxxxxxxxxxxx>]

> [Dario was forgotten in this email. Adding him back..:-( ]

Gah, how did I forget this! I've been meaning to make a text file of the command so I never forget anyone.

> > Sorry for the repeated send to the mailing list, I forgot to add some
> > cc's and wanted to make sure
> > everyone was included.
> >
> > This is the new patch that works towards how Dario suggested
> > structuring the event-driven move.
> > It uses the previous timer to drive the rt_schedule function, which
> > enforces budget depletions and
> > performs scheduling decisions.
>
> This is more like a cover letter. Next time, can you use the option
> --compose to send a cover letter with the detailed design along with
> the patch?
>
> You can also link to the discusssion we had about the design.

I guess this could be useful to be mentioned in a cover letter.

> >
> > There is an added timer that only handles replenishments, which is
> > called at the time the next
> > replenishment will occur. To do this, we now also keep the depletedq
> > sorted. If it detects it has
> > moved a vCPU into the first [# CPUs] slots in the runq, it tickles the
> > runq with the added vCPU.
> > If the depletedq becomes empty the timer is stopped, and if the
> > scheduler moves a vCPU into
> > a previously empty depletedq it restarts the timer.
> >
> > This may have some issues with corner cases that were discussed
> > earlier, such as unexpected
> > behavior if the two timers are armed for the same time. It should be
> > correct for the common case.
>
> Could you elaborate more about when two timers can be armed for the same time?

Since the two timers are independent now, if a task on the depletedq has deadline at time X (so the replenishment timer will run) and another task on a CPU runs out of budget at time X (so scheduler should run), its not clear what will happen. If the replenishment goes first it probably isn't a big deal. However, if rt_schedule goes first it may kick a vcpu that is about to get a replenishment that would cause it to remain a top priority. One easy option is to check replenishments before kicking a vcpu, but that's exactly the kind of stuff we wanted to avoid with this restructuring. Additional logic to enforce a replenishment always goes first may be more than we would like. I'll have to look more into the Xen timer behavior with these regards to this matter.

~Dagaen Golomb

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