WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: [Xen-ia64-devel] metaphysical mode

To: "Yoshi. Oguchi" <y-oguchi@xxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] metaphysical mode
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Mon, 5 Dec 2005 09:50:45 -0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 05 Dec 2005 17:50:50 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcX5c9Jo54GCxYKCSXWyjvt9pBTRngAUB5pg
Thread-topic: [Xen-ia64-devel] metaphysical mode
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

<Prev in Thread] Current Thread [Next in Thread>