> [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@lists.xen.org http://lists.xen.org/xen-devel