Folks, Things are beginning to come together, and I think the target of forking off the 3.0-testing tree before OLS (e.g. around July 16) is tough but just about attainable. We won''t quite be in a position where the 3.0-testing tree is purely bug fixes only, but everything that will remain to be incorporated before 3.0.0 is self contained and relatively low risk. The key items we''ve got to finish off before the 3.0-testing fork are: 1. integration of new time API. [This is close to working] 2. switching block, net and console over to xenbus/xenstore. [lots to do!] 3. integrating Vincent''s 2.6.12 upgrade patch and the net grant tables patch. [easy] 4. x86_32 PAE dom0 patches. [fairly close] We''re also keen to see the following incorporated if possible: 5. x86_64 using writeable pagetables interface, ideally SMP too. [plenty to do] 6. Stephan''s simple CPU load ballancer. [prototype close] 7. x86_32 PAE domU builder patches [plenty to do] 8. save/restore of multi VCPU contexts [plenty to do] The critical path item is #2 (switching block, net and console over to xenbus/xenstore). This seems to be making decent progress over the last few days though. It''s important that we get this feature in ASAP as it''s a high-risk Xen API-changing feature that we want to undergo the full testing cycle. The key feature that 3.0-testing will be missing is save/restore/migrate for x86_64 and x86_32 PAE. Even for plain x86_32 save/restore/migrate wont be particularly well tested going in to 3.0-testing as we need the tools work complete before we can give it a good work out. We should be able to incorporate and test the outstanding save/restore/migrate issues before 3.0.0. For more detail see the developer section on the wiki. As regards testing, we''re working on a number of different fronts to get some good infrastructure in place: * 3.0-testing CD. This is a live ISO like the demo CD, but is used to test Xen on the underlying hardware platform. We''re hoping that as many members of the community as possible will try the test CD on their platforms and report the results via a web form. We''ll collate the information and maintain a summary web page. * New regression test suite. We''re working on a sophisticated test suite that will run a wide range of benchmarks and test programs [lmbench, ttcp, ltp, kernbench, reaim, postmark, osdb/postgresql, ace tcp_test, specjbb, tbench, dbench, crashme] under a variety of situations [UP and SMP domains, multiple concurrent domains, communicating domains etc.] The final phase of the test will also exercise the tools, adding/removing CPUs, adding/removing memory, migrating domains etc. This is going to be a really good work out for xen and guest kernels. Stay tuned... Best, Ian Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt <m+Ian.Pratt <at> cl.cam.ac.uk> writes:> Things are beginning to come together, and I think the target of forking > off the 3.0-testing tree before OLS (e.g. around July 16) is tough but > just about attainable. We won''t quite be in a position where the > 3.0-testing tree is purely bug fixes only, but everything that will > remain to be incorporated before 3.0.0 is self contained and relatively > low risk.Since the semantics of the tree is a bit different from 2.0-testing might it make sense to use a different name, e.g. pre-3.0? Also, will the 3.0-testing tree be appropriate to roll in common-izing changes (i.e. abstracting out x86-isms) in drivers and xc? These should be low risk to x86_* as they will simply be syntactic, e.g. moving inline code into macros or separate functions. If so, I''d like to arrange some time to work on this at OLS? Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Since the semantics of the tree is a bit different from > 2.0-testing might it make sense to use a different name, e.g. pre-3.0?Not so different. Changing tree names is actually a pain in the butt, so I think 3.0-testing is actually OK. We will then fork 3.0 from it when we''re ready for a release (and tag it 3.0.0), and 3.0-testing will be strictly bug fixes only. We''re not intending to do any checkins to -unstable until 3.0 is released. In fact, we might start off soft linking the -unstable repo to -3.0-testing.> Also, will the 3.0-testing tree be appropriate to roll in > common-izing changes (i.e. abstracting out x86-isms) in > drivers and xc? These should be low risk to x86_* as they > will simply be syntactic, e.g. moving inline code into macros > or separate functions. If so, I''d like to arrange some time > to work on this at OLS?I''d have rather hoped stuff like this would have already been discussed and posted :-( Anyhow, we can try and find time to discuss this at OLS with both you and Jimi, Hollis et al. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 1. 3.0-testing (Ian Pratt) > * New regression test suite. We''re working on a sophisticated test > suite that will run a wide range of benchmarks and test programs > [lmbench, ttcp, ltp, kernbench, reaim, postmark, osdb/postgresql, ace > tcp_test, specjbb, tbench, dbench, crashme] under a variety of > situations [UP and SMP domains, multiple concurrent domains, > communicating domains etc.] The final phase of the test will also > exercise the tools, adding/removing CPUs, adding/removing memory, > migrating domains etc. This is going to be a really good work out for > xen and guest kernels. Stay tuned...(Sorry about the strange reply/subject. It appears gmane is down (which is my usual method for followup since I subscribe to the digest version.) Sounds cool! Will this be available for others to use? It would be great if the suite is well parameterized so it is possible to easily turn off individual tests or classes of tests. Then it can be used by ports that are not as far along as x86. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Magenheimer, Dan (HP Labs Fort Collins) wrote:>> 1. 3.0-testing (Ian Pratt) >> * New regression test suite. We''re working on a sophisticated test >>suite that will run a wide range of benchmarks and test programs >>[lmbench, ttcp, ltp, kernbench, reaim, postmark, osdb/postgresql, ace >>tcp_test, specjbb, tbench, dbench, crashme] under a variety of >>situations [UP and SMP domains, multiple concurrent domains, >>communicating domains etc.] The final phase of the test will also >>exercise the tools, adding/removing CPUs, adding/removing memory, >>migrating domains etc. This is going to be a really good work out for >>xen and guest kernels. Stay tuned... > > > (Sorry about the strange reply/subject. It appears gmane is down (which > is > my usual method for followup since I subscribe to the digest version.) > > Sounds cool! Will this be available for others to use?The idea is it will eventually be released, but we''re still developing it atm.> > It would be great if the suite is well parameterized so it is possible > to easily turn off individual tests or classes of tests. Then it > can be used by ports that are not as far along as x86.Thats the idea yeah. Tom> > Dan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 2005-07-11 at 06:55 -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:> > 1. 3.0-testing (Ian Pratt) > > * New regression test suite. We''re working on a sophisticated test > > suite that will run a wide range of benchmarks and test programs > > [lmbench, ttcp, ltp, kernbench, reaim, postmark, osdb/postgresql, ace > > tcp_test, specjbb, tbench, dbench, crashme] under a variety of > > situations [UP and SMP domains, multiple concurrent domains, > > communicating domains etc.] The final phase of the test will also > > exercise the tools, adding/removing CPUs, adding/removing memory, > > migrating domains etc. This is going to be a really good work out for > > xen and guest kernels. Stay tuned... > > (Sorry about the strange reply/subject. It appears gmane is down (which > is > my usual method for followup since I subscribe to the digest version.) > > Sounds cool! Will this be available for others to use? > > It would be great if the suite is well parameterized so it is possible > to easily turn off individual tests or classes of tests. Then it > can be used by ports that are not as far along as x86.Have you looked at Xentest? Xentest lets you very easily add/remove tests with a few lines in a config file. We should be making an updated release soon. -- Thanks, Paul Larson plars@linuxtestproject.org http://www.linuxtestproject.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Magenheimer, Dan (HP Labs Fort Collins)
2005-Jul-12 18:40 UTC
RE: [Xen-devel] RE: 3.0-testing
> Have you looked at Xentest? Xentest lets you very easily add/remove > tests with a few lines in a config file. We should be making > an updated > release soon.Can you provide a pointer? Google doesn''t find much.> -----Original Message----- > From: Paul Larson [mailto:plars@linuxtestproject.org] > Sent: Monday, July 11, 2005 10:24 AM > To: Magenheimer, Dan (HP Labs Fort Collins) > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] RE: 3.0-testing > > On Mon, 2005-07-11 at 06:55 -0700, Magenheimer, Dan (HP Labs Fort > Collins) wrote: > > > 1. 3.0-testing (Ian Pratt) > > > * New regression test suite. We''re working on a > sophisticated test > > > suite that will run a wide range of benchmarks and test programs > > > [lmbench, ttcp, ltp, kernbench, reaim, postmark, > osdb/postgresql, ace > > > tcp_test, specjbb, tbench, dbench, crashme] under a variety of > > > situations [UP and SMP domains, multiple concurrent domains, > > > communicating domains etc.] The final phase of the test will also > > > exercise the tools, adding/removing CPUs, adding/removing memory, > > > migrating domains etc. This is going to be a really good > work out for > > > xen and guest kernels. Stay tuned... > > > > (Sorry about the strange reply/subject. It appears gmane > is down (which > > is > > my usual method for followup since I subscribe to the > digest version.) > > > > Sounds cool! Will this be available for others to use? > > > > It would be great if the suite is well parameterized so it > is possible > > to easily turn off individual tests or classes of tests. Then it > > can be used by ports that are not as far along as x86. > Have you looked at Xentest? Xentest lets you very easily add/remove > tests with a few lines in a config file. We should be making > an updated > release soon. > > -- > Thanks, > Paul Larson > plars@linuxtestproject.org > http://www.linuxtestproject.org >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Magenheimer, Dan (HP Labs Fort Collins) wrote:>>Have you looked at Xentest? Xentest lets you very easily add/remove >>tests with a few lines in a config file. We should be making >>an updated >>release soon. >> >> > >Can you provide a pointer? Google doesn''t find much. > >The xen-devl mailing list archives would be a better place to look. I''ll be making another release later this week too if you''d like to just wait for that. The new version has a much better results directory layout, a facility for specifying patches to apply against the xen tree before building it, and several fixes. Thanks, Paul Larson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel