From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: [PATCH] [RFC] Building guests on monotonic Xen system time Date: Tue, 3 Jun 2008 13:47:13 -0600 Message-ID: <20080603134713906.00000002776@djm-pc> References: Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , "Xen-Devel (E-mail)" Cc: Dave Winchell List-Id: xen-devel@lists.xenproject.org > I have a pretty clear vision of what I want now, so I will make the > necessary adjustments to the patch. Then we can go from there = I noticed you fixed a related bug (cset 17760), but haven't seen anything that changes timer_mode=3D=3D0 back to non-monotonic. Is that still on your list, or do you want me to submit a patch for that? Related, I'm wondering if we should change the defaults for timer_mode and hpet now. I'll start a new thread on that to avoid topic drift. Dan = > -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Saturday, May 24, 2008 1:34 AM > To: dan.magenheimer@oracle.com; Xen-Devel (E-mail) > Cc: Dave Winchell > Subject: Re: [Xen-devel] [PATCH] [RFC] Building guests on = > monotonic Xen > system time > = > = > On 23/5/08 23:44, "Dan Magenheimer" = > wrote: > = > > Here's another option: I think delay_for_missed_ticks is > > the only mode where time must be set backwards. All of the > > other modes track wallclock. It looks possible that we > > could enforce monotonicity for the other three modes and > > not enforce it for delay_for_missed_ticks (which is, > > unfortunately, the default). > > > > If this is acceptable to you (and you don't disagree with > > my "only mode...set backwards" conjecture), I'll try to > > code a patch for this. > = > I agree with your analysis. I couldn't remember if any modes = > other than 0 > would require non-monotonic time across VCPUs, but it does = > appear that this > property is exclusive to mode 0. > = > > P.S. I think the answer is no, but is there any way to specify > > gang-scheduling for a domain? If so, we could say if your > > OS is non-resilient to preemption and your application requires > > time monotonicity, you must specify gang scheduling. > = > There isn't currently a way to request gang scheduling. I = > think that is a > second step anyway. It sounds like you could simply turn off your > monotonicity checks for timer mode 0 and I'll be happy. > = > I have a pretty clear vision of what I want now, so I will make the > necessary adjustments to the patch. Then we can go from there = > if you think > further modifications are required. > = > -- Keir > = > = >