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

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> 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.

Do you have a NOW() macro yet?  That'd be where I'd look.

> 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.)

It should be OK once tracked down - there's not a lot of arch dep code in 
there?

> 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!)

I had a nasty feeling you'd say that :-(  I suppose having a dom0 op to invoke 
Xen key handlers wouldn't be a bad idea in some ways (would also be useful on 
machines with no serial line at all).

Cheers,
Mark

>
> 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

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