> Do you have a NOW() macro yet? That'd be where I'd look.
Yes, that's in common code. However it looks like all the
time code needs some work (see for example arch/ia64/time.c:
update_dom_time()). There's apparently some previously
unexercised dependencies between the scheduler and time
management.
Is there another scheduler that's less dependent on time
that we can use until things get fixed up?
Dan
> -----Original Message-----
> From: Mark Williamson [mailto:mark.williamson@xxxxxxxxxxxx]
> Sent: Friday, April 15, 2005 8:22 AM
> To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Magenheimer, Dan (HP Labs Fort Collins); Mark Williamson;
> ipf-xen@xxxxxxxxx
> Subject: Re: [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.
>
> 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
|
Home