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