'RE: [Xen-ia64-devel] Re: Please try latest xen/ia64 on'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xen-ia64-devel
Subject:    RE: [Xen-ia64-devel] Re: Please try latest xen/ia64 on
From:       "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer () hp ! com>
Date:       2005-04-15 15:14:30
Message-ID: 516F50407E01324991DD6D07B0531AD535AAEF () cacexc12 ! americas ! cpqcorp ! net
[Download RAW message or body]

> 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@cl.cam.ac.uk] 
> Sent: Friday, April 15, 2005 8:22 AM
> To: xen-ia64-devel@lists.xensource.com
> Cc: Magenheimer, Dan (HP Labs Fort Collins); Mark Williamson; 
> ipf-xen@intel.com
> 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@cl.cam.ac.uk]
> > > Sent: Friday, April 15, 2005 8:04 AM
> > > To: xen-ia64-devel@lists.xensource.com
> > > Cc: Haavard Bjerke; Magenheimer, Dan (HP Labs Fort Collins);
> > > ipf-xen@intel.com
> > > 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@cern.ch]
> > > > > > Sent: Tuesday, April 12, 2005 3:41 AM
> > > > > > To: Magenheimer, Dan (HP Labs Fort Collins)
> > > > > > Cc: ipf-xen@intel.com; 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@lists.xensource.com
> > > > http://lists.xensource.com/xen-ia64-devel
> >
> > _______________________________________________
> > Xen-ia64-devel mailing list
> > Xen-ia64-devel@lists.xensource.com
> > http://lists.xensource.com/xen-ia64-devel
> 

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

[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic