Re: [Xen-ia64-devel] metaphysical mode

["Yoshi. Oguchi" <y-oguchi@xxxxxxxxxxxxxx>]

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