WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: [Xen-ia64-devel] Re: Please try latest xen/ia64 on xen-ia64.bkbits.n

To: "Mark Williamson" <maw48@xxxxxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Re: Please try latest xen/ia64 on xen-ia64.bkbits.net
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Fri, 15 Apr 2005 07:41:30 -0700
Cc: ipf-xen@xxxxxxxxx
Delivery-date: Fri, 15 Apr 2005 14:41:19 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: DIscussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVBx5GPUqiLnpieSfSZxwrb0THEvgAAKBmw
Thread-topic: [Xen-ia64-devel] Re: Please try latest xen/ia64 on xen-ia64.bkbits.net
Haavard -- Good work tracking this down!  Apparently
we need to find where the time-used is recorded... it
must be in the arch-dep code in x86 and hasn't made its
way into the equivalent ia64 code yet.  Alternately
perhaps we could switch to a different default
scheduler?  (Since sched_bvt.c is common code, we
won't be able to get your change in.) 

Mark -- Xen/ia64 doesn't have keyboard input (yet) so
the keyhandler routines don't work.  (We need a volunteer
with serial port expertise to work on this... and get
the serial input code more generalized too!  It is
currently a very bad hack!)

Dan

> -----Original Message-----
> From: Mark Williamson [mailto:maw48@xxxxxxxxxxxx] 
> Sent: Friday, April 15, 2005 8:04 AM
> To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Haavard Bjerke; Magenheimer, Dan (HP Labs Fort Collins); 
> ipf-xen@xxxxxxxxx
> Subject: Re: [Xen-ia64-devel] Re: Please try latest xen/ia64 
> on xen-ia64.bkbits.net
> 
> Oh dear!  That's not nice.
> 
> MCU advance is the inverse of a domain's weight in BVT.  If 
> it's zero then the 
> domain will always be more important than anything else :-(
> 
> As far as I know this should only change if the userspace 
> scheduler control 
> tools request it, so it's rather weird.
> 
> What happens if you invoke the "Dump runqueues" key handler 
> on the serial line 
> (sorry, I forget which key this is exactly).  This'll output 
> (amongst other 
> things) the MCU advance, the evt and the avt per domain.  
> Might give us an 
> idea what it thinks it's doing!
> 
> Cheers,
> Mark
> 
> 
> 
> On Friday 15 April 2005 12:42, Haavard Bjerke wrote:
> > This is what I've found out so far -
> >
> > Apparently, domU is never scheduled, because the actual 
> (AVT) and effective
> > virtual times of dom0 are not increased as dom0 runs, so 
> dom0 is always
> > favored by the BVT scheduler.
> >
> > The problem seems to be the inc->mcu_advance variable, 
> which decides how
> > much AVT is increased per dispatch. This is initially set 
> to MCU_ADVANCE (=
> > 10) in do_createdomain(), but in the scheduler, in 
> calc_avt(), it is read
> > as 0, so AVT isn't increased.
> >
> > I don't understand why the inc->mcu_advance variable is 
> changed to 0, but
> > when applying the following hack in sched_bvt.c:calc_avt(), 
> domU is loading
> > again:
> >
> > static inline u32 calc_avt(struct exec_domain *d, s_time_t now)
> > {
> >     ...
> >
> >     if(dom1_scheduled && d->domain->id == 0){
> >         inf->mcu_advance = MCU_ADVANCE;
> >     }
> >
> >     return einf->avt + mcus * inf->mcu_advance;
> > }
> >
> > Håvard
> >
> > On Tue, Apr 12, 2005 at 03:51:25PM -0700, Magenheimer, Dan 
> (HP Labs Fort 
> Collins) wrote:
> > > I can confirm the latest symptoms when trying to launch
> > > a domU: domU gets set up but never seems to get scheduled.
> > > Indeed several domU's can be launched and nothing gets
> > > scheduled.  In all cases (for me at least), dom0 continues
> > > to run.
> > >
> > > I suspect that this is a softirq delivery problem similar to
> > > the one you (Haavard) saw and identified a fix for last week.
> > >
> > > Dan
> > >
> > > P.S. Note xen-ia64-devel list cc'ed but I haven't seen
> > > anyone from Intel sign up yet so have also cc'ed ipf-xen@intel
> > > for now.
> > >
> > > > -----Original Message-----
> > > > From: Haavard Bjerke [mailto:havard.bjerke@xxxxxxx]
> > > > Sent: Tuesday, April 12, 2005 3:41 AM
> > > > To: Magenheimer, Dan (HP Labs Fort Collins)
> > > > Cc: ipf-xen@xxxxxxxxx; Haavard Bjerke; Greg Edwards; 
> Eranian, Stephane
> > > > Subject: Re: Please try latest xen/ia64 on xen-ia64.bkbits.net
> > > >
> > > > It seems to be working fine here. Except, with this new
> > > > build, loading domU doesn't work at all; not even your
> > > > xenlinux26112 binary.
> > > >
> > > > This is where domU stops:
> > > >
> > > > (XEN) domain mem: type=0, attr=0x0,
> > > > range=[0x0000000000000000-0x0000000000000000) (0M)
> > > > (XEN) new_thread, done with dom_fw_setup
> > > > (XEN) new_thread returns
> > > > (XEN) current=f000000007fe0000,shared_info=f000000007fd8000
> > > >
> > > > FYI,
> > > > Håvard
> > > >
> > > > On Mon, Apr 11, 2005 at 03:09:54PM -0700, Magenheimer, Dan
> > > >
> > > > (HP Labs Fort Collins) wrote:
> > > > > I have integrated Greg Edwards' update of Xen/ia64 to
> > > > > use Linux 2.6.11 files, tested it, and pushed it to
> > > > > xen-ia64.bkbits.net/xeno-unstable-ia64.bk.
> > > > >
> > > > > NOTE that this release requires a linux-2.6.11 directory
> > > > > (NOT linux-2.6.11.2 or later!) where the linux-2.6.7
> > > > > directory was before (sister directory to 
> xeno-unstable-ia64.bk).
> > > > >
> > > > > It is not recommended to pull this into an existing
> > > > > bk tree as mkbuildtree will NOT work properly.
> > > > > Please clone a new bk tree, run mkbuildtree, and
> > > > > try it out.
> > > > >
> > > > > After it gets a little mileage, I will ask Keir to pull
> > > > > it into the main Xen tree.
> > > > >
> > > > > Thanks,
> > > > > Dan
> > > > >
> > > > > P.S. Greg -- I moved the changes from common files into
> > > > > arch files to avoid debate.  I will fix this up later if/when
> > > > > the common files change.
> >
> > _______________________________________________
> > Xen-ia64-devel mailing list
> > Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-ia64-devel
> 

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel