RE: [Xen-ia64-devel] metaphysical mode

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

> > 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