RE: [Xen-ia64-devel] metaphysical mode

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

> This sounds like orthogonal issues.  Why different supports 
> can't be proceeded parallel with stability of DomainU?  Why 
> it must be in sequence?  This really bothers me!  Scalability 
> is key factor for Xen/ia64 big irons to achieve overall 
> platform performance, we should build the infrastructure for 
> it ASAP in order to get system-wide performance early.  

I don't see why you think it is orthogonal.  If you spend
all your time improving the performance of something that
you can't even run -- and certainly can't measure -- then
you will only run nothing very fast.

> However FAST_* can be more important than scalability features?  

I never said that.  The FAST_* paths were implemented after
domain0 was stable.  Basic functionality was implemented first
(remember the privify tool?), then basic paravirtualization
techniques were applied, then real measurements were used to identify
where the bottlenecks were.  Finally those bottlenecks were
coded as FAST_* paths.  All along, the fast paths were designed
to be easily disabled -- and some were.  For example, FAST_TICK is
still disabled because it appeared in July to cause a problem when
starting a second domain.

Scalability has no value unless you can run big apps (e.g.
databases, mail servers, data mining).  We cannot even run
little apps in domU today.  I fail to see why we should disable
tested performance improvements (FAST_* paths) that benefit all
applications, because we speculate that some VHPT changes
may benefit some large applications on some large systems sometime
in the future.

> Why "Next phase of Xen/ia64 development" comments was asked?  
> Isn't that to get the community consensus and members can 
> contribute their efforts into different area?

I am merely expressing my opinion.  I think
the whole purpose of the Xen/ia64 community is to deliver
a reliable fully-functioning Xen product to as many Itanium vendors
and users as possible, as soon as possible.  Some vendors and users
may consider 64-way guests to be more important than migration,
others may be looking for multiple OS support (e.g. Windows),
and others may consider a 5% performance degradation to be too
much.  But Itanium users are generally enterprise customers
who have high expectations for the stability of their system
software.  None of them will even consider trying Xen/ia64 if
we can't run a compiler -- let alone an enterprise app -- in
multiple domains.

In my reply to Eddie, I noted that basic block I/O and multiple
domain support was implemented five months ago but is not
much more stable now than it was then.  If "community members
contribute their efforts into different area", but insufficient
effort is put into basic functionality and stability, we
do not have a community... we have anarchy.

This is why I think we need to work on domU stability.  And stability
cannot be measured or improved effectively without an automated
regression test suite.  And an automated regression test suite
will be very hard to implement without networking support.
That's why I believe these are the top three priorities.

Dan


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