[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Questions about the use of idle_vcpu[]
On 1/18/2016 11:07 AM, Meng Xu wrote: On Mon, Jan 18, 2016 at 6:00 AM, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:On Mon, 2016-01-18 at 10:47 +0000, George Dunlap wrote:On Fri, Jan 15, 2016 at 1:04 AM, Tianyang Chen <tiche@xxxxxxxxxxxxxx>If an idle vcpu is picked, the ret.time is set accordingly in both credit and credit2 by checking whether snext is idle. if so, credit returns -1 and credit2 returns 2ms. However, there is no corresponding code in the RTDS scheduler to handle this. When an idle_vcpu is picked, the value of ret.time would be 0 and the scheduler would be invoked again. What is the logic behind this?No real logic, as far as I can tell. :-) The ret.time return value tells the generic scheduling code when to set the next scheduler timer. According to the comment in xen/common/schedule.c:schedule(), returning a negative value means "don't bother setting a timer" (e.g., no time limit). So credit1 does the right thing.It does.Then the RTDS is doing *incorrectly* right now. :-( George: Thanks. After looking at idle_loop() it makes sense now. Even though an idle vcpu won't tell scheduler timer when to fire next time, do_tasklet() checks if all tasklets on the list are finished and then raise SCHEDULE_SOFTIRQ. Dario: I had some discussion with Meng recently and the second version will soon come out. You can directly comment on it if that saves you some time.It looks like credit2's behavior will probably prevent the processor from going into deeper power-saving states, and rtds' behavior might cause it to essentially busy-wait.RTDS behavior is broken in many respect, including this, and in fact, Meng and Tianyang are sending patches already to fix it (I'll let you guys have my comments shortly :-P).Right. Tianyang and I are working on changing it from quantum driven model to event-driven (or called timer-driven) model. Tianyang sent out the first-version patch, but that version has some problems. He is working on the second version now. Hi Dario, Tianyang is working on the second version right now. If you could have a quick look at our discussion in that thread and points out the "serious" issues in the decision, that will be great! We won't repeat the error again and again in the following versions. As to the minor issues, we could refine it in the second version. (I'm just thinking about how to save your time to have this done. For the obvious things that I can handle, I will do it and avoid "wasting" you time. For the design choices that we are unclear, we definitely need your insights/commands. ;-) ) Thanks, Tianyang _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |