RE: [Xen-ia64-devel] metaphysical mode

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

Excellent!  Thanks for your offer of help!  It is gladly
accepted!

One other idea would be to have a stress test.  Something
that generates a lot of activity, such as maybe compiling
all of Xen (make world) *twice in parallel* (both in background)

Thanks,
Dan

> -----Original Message-----
> From: Yoshi. Oguchi [mailto:y-oguchi@xxxxxxxxxxxxxx] 
> Sent: Monday, December 05, 2005 1:12 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: Dong, Eddie; Yang, Fred; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-ia64-devel] metaphysical mode
> 
> Hi Dan and all
> 
> Our members can do daily(or 2-3 times a week) regression
> tests for the latest IPF/Xen snapshot.
> 
> I'm thinking of running ltp/lmbench/xm-test etc on Dom0/DomU and 
> reporting the result to the community.
> 
> At the start it will be half-manual/half-automated, but
> we'll make it fully-automated later.
> 
> If this kind of regression test is helpful, I'd happy to do that.
> 
> >A good automated regression test suite would be a big contribution
> >to the community but will be time-consuming.  I would like to see
> >someone else in the community drive this.
> >
> 
> Thanks,
> 
> Yoshi Oguchi
> ---
> Magenheimer, Dan (HP Labs Fort Collins) wrote:
> >> > I am still in favor of testing multiple VHPT solutions.
> >> > However, I don't think there are any functionality
> >> > reasons why a per-VP VHPT is necessary, it is just
> >> > a performance issue, correct?   
> >> Mmm, Not quit that.
> >> What Anthony doing is to enable functionality ("collision 
> >> chain and soft
> >> TLB)
> >> I believe you'd like to see this is enabled, right ? :-) 
> >> The current VHPT implementation still need to enable a lot of
> >> functionality 
> >> to support SMP guest. If you look at what is done in vcpu.c now, 
> >> all the ptc_l/ptc_g/ptr are not done yet. even itc need a lot 
> >> of effort
> >> when collision chain is enabled. Don't you want to see the VHPT
> >> implementation to be ready for SMP support?
> >> 
> >> We need to plan more than what is doing now, right?
> >
> >There is definitely some missing virtual memory functionality
> >that will be necessary to implement before SMP guests will
> >work at all (e.g. purge instructions); implementing something
> >that is a no-op today won't cause regressions. And I do believe
> >that collision chains and some alternate VHPT solutions may show
> >a significant performance impact on some large system
> >benchmarks.  However neither SMP guest nor large benchmark
> >performance will be relevant if we cannot even run a domU
> >long enough to run large benchmarks or even simple tests.
> >Also, I don't think there are any large system benchmarks
> >that will run without networking.
> > 
> >Basic block I/O and multiple domains were implemented five
> >months ago and domU is not any more stable than it was then.
> >The community needs to work together to make this happen and, yes,
> >I think this is higher priority than VHPT performance enhancements
> >or fixes to theoretical bugs.
> >
> >> > Right now we do not have a very good regression test
> >> > process.  Even if we did have one, domU is not yet
> >> > stable enough to run it.
> >> 
> >> Agree, we'd better to define a better regression test 
> process so that
> >> people can follow. Can u drive this? 
> >
> >I already spend a huge percentage of my time -- both HP's time and
> >my personal time --  on "tax", meaning things that are necessary
> >to be done for the sake of the Xen/ia64 community, but are not fun
> >for me, are unrewarding, and not part of my job description.
> >
> >A good automated regression test suite would be a big contribution
> >to the community but will be time-consuming.  I would like to see
> >someone else in the community drive this.
> >
> >> BTW, following paragraph is copied from your previous email 
> >> sent in Sep
> >> 2nd.
> >> Certainly, blocking upstream 1-2 days for domU is OK, but we 
> >> still need
> >> to forward
> >> progress in parallel, right? Especially different people in the
> >> community may have 
> >> different focus.
> >> 
> >> "I haven't yet merged in the changes that you and Kevin
> >> have been posting so I'm sure tip wouldn't work.  Now
> >> that I've gotten through all the maintenance work,
> >> I will apply the patch to xen... even if it is incomplete,
> >> it won't be any worse than what is there now."
> >
> >I'm not sure what the point of the quote is.
> >
> >I am not blocking forward progress.  I am just trying to ensure
> >that the core tree that *everybody* uses does not have regressions
> >due to one person's pet project.  A good regression test suite is
> >necessary to ensure this.  And without a functioning stable
> >domU, we cannot have a good regression test suite.
> >
> >> > Some in the community have been angry with me for committing
> >> > changes that have not been fully tested and cause regressions.
> >> > Once you can say "this new code has passed the full regression
> >> > suite", it will be much easier for me to commit a change.
> >> 
> >> Agree, so I would like to suggest all the patches want to 
> >> check into hg
> >> should 
> >> be posted in the mailing list first so that people can 
> >> provide feedback,
> >> 
> >> does that make sense?
> >
> >It definitely makes sense to post to the mailing list first.
> >But studying a patch is not a substitute for exercising it
> >and ensuring there are no regressions.
> >
> >Dan
> >
> >_______________________________________________
> >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