From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tianyang Chen Subject: Re: Questions about the use of idle_vcpu[] Date: Tue, 19 Jan 2016 17:59:15 -0500 Message-ID: <569EBFC3.6050701@seas.upenn.edu> References: <569845B7.2060207@seas.upenn.edu> <1453114800.11427.78.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli , George Dunlap Cc: Meng Xu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 1/18/2016 11:07 AM, Meng Xu wrote: > On Mon, Jan 18, 2016 at 6:00 AM, Dario Faggioli > wrote: >> >> On Mon, 2016-01-18 at 10:47 +0000, George Dunlap wrote: >>> On Fri, Jan 15, 2016 at 1:04 AM, Tianyang Chen >>> >>>> 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. >> >> >>> 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. ;-) ) > 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. Thanks, Tianyang