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