* Re: Regression testing of 2.4.x before release? [not found] <Pine.LNX.4.33.0111040832060.364-100000@mikeg.weiden.de> @ 2001-11-04 17:58 ` Dan Kegel 2001-11-04 19:09 ` Luigi Genoni 0 siblings, 1 reply; 18+ messages in thread From: Dan Kegel @ 2001-11-04 17:58 UTC (permalink / raw) To: Mike Galbraith, linux-kernel, stp Mike Galbraith wrote: > > On Sat, 3 Nov 2001, Dan Kegel wrote: > > > I get the impression that Alan stress-tests his kernels > > more than Linus does before releasing them. > > That's _our_ collective job. We're supposed to beat the snot out > of the -pre kernels and report. One guy can't cover effectively, > even if his name is Linus "stress-testing is boring" Torvalds ;-) I'm not saying Linus should do the testing. It's good that Linus is asking others to test with cerberus, as he did in http://marc.theaimsgroup.com/?l=linux-kernel&m=100451768023436&w=2 It would be even better if Linus came out and stated that he would refuse to call a kernel final if there is an outstanding report of it failing an agreed-upon set of stress tests. And it would be *even better* if http://osdl.org/stp/ were used to do stress testing in a nice, automated way on 1, 4, 8, and 16-cpu machines on release candidates. Almost none of this requires any work by Linus. All Linus has to do is say "The 2.4.x kernels will pass stress tests before release", and recruit someone to run his kernels through OSDL's STP in a timely manner. (I'd be happy to help if it weren't for my darn tendinitis, which makes it hard even to stir up trouble on mailing lists these days.) - Dan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-04 17:58 ` Regression testing of 2.4.x before release? Dan Kegel @ 2001-11-04 19:09 ` Luigi Genoni 2001-11-05 1:51 ` Dan Kegel 2001-11-05 16:39 ` Timothy D. Witham 0 siblings, 2 replies; 18+ messages in thread From: Luigi Genoni @ 2001-11-04 19:09 UTC (permalink / raw) To: Dan Kegel; +Cc: Mike Galbraith, linux-kernel, stp Problem is: there is a lot of HW out there, and we should ALL do stress tests, to have a wide basis for HWs and test cases. Basically it is very hard to agree about a set of stress tests, because we all have different needs, and our tests are based on our needs. That is a streght, because they tend to be real life tests. In my esperience, if some default set of tests comes out, then software tend to be optimized for this set. And that is badly wrong. Our disomogeneous tests are a good thing indeed. For example, with servers with not so mutch memory (128/256 Mbyte RAM 256/512 MByte SWAP) I am interested for interactive uses, because usually I have 20/50 users connected to them using Xwin (from X session on localhost and many Xterms), netscape, KDE, a lot of mail software and TeX. With bigger Iron (sparc64 with some Gbytes of RAM/SWAP) I am mutch more interested in DB performances and web servers with zope and other application servers. My stress test have been developed during those years thinking on my needs. Thanx to this test, it was possible to see some VM bugs that was very difficoult to be seen under other conditions. Then it was easy to work with AA to fix them, and I have to say, he has been always available and interested to solve every problem. Other people will test other cases. Then it belongs to Linus to see if he is satisfied with reports. He can just take advantage of actual situation with testers. This way Linux has a lot of possibility to run well on the most HW (I am also thinking to alpha, sparc64, mips ecc.), and with the most cases. On Sun, 4 Nov 2001, Dan Kegel wrote: > Mike Galbraith wrote: > > > > On Sat, 3 Nov 2001, Dan Kegel wrote: > > > > > I get the impression that Alan stress-tests his kernels > > > more than Linus does before releasing them. > > > > That's _our_ collective job. We're supposed to beat the snot out > > of the -pre kernels and report. One guy can't cover effectively, > > even if his name is Linus "stress-testing is boring" Torvalds ;-) > > I'm not saying Linus should do the testing. > > It's good that Linus is asking others to test with cerberus, as he > did in http://marc.theaimsgroup.com/?l=linux-kernel&m=100451768023436&w=2 > > It would be even better if Linus came out and stated that he would > refuse to call a kernel final if there is an outstanding report of > it failing an agreed-upon set of stress tests. > > And it would be *even better* if http://osdl.org/stp/ were used > to do stress testing in a nice, automated way on 1, 4, 8, and 16-cpu > machines on release candidates. > > Almost none of this requires any work by Linus. All Linus has to > do is say "The 2.4.x kernels will pass stress tests before release", > and recruit someone to run his kernels through OSDL's STP in a > timely manner. > > (I'd be happy to help if it weren't for my darn tendinitis, which > makes it hard even to stir up trouble on mailing lists these days.) > - Dan > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-04 19:09 ` Luigi Genoni @ 2001-11-05 1:51 ` Dan Kegel 2001-11-05 16:39 ` Timothy D. Witham 1 sibling, 0 replies; 18+ messages in thread From: Dan Kegel @ 2001-11-05 1:51 UTC (permalink / raw) To: Luigi Genoni; +Cc: Mike Galbraith, linux-kernel, stp Luigi Genoni wrote: > Problem is: > there is a lot of HW out there, and we should ALL do stress tests, to have > a wide basis for HWs and test cases. Basically it is very hard to agree > about a set of stress tests, because we all have different needs, and our > tests are based on our needs. That is a streght, because they tend to be > real life tests. Sure, no argument there. > In my esperience, if some default set of tests comes out, then software > tend to be optimized for this set. And that is badly wrong. My post was motivated by two observations: 1. Alan Cox complains occasionally that Linus' trees are not well tested, and can't survive the torture tests that the ac tree goes through before release. (e.g. "2.4.8-ac12 I'm trying to make sure I can keep this testable as 2.4.9 vanilla isnt being stable on my test sets " 2. The STP at OSDLab seems like a great resource that we might be able to leverage to solve the problem Alan points out. I'm not suggesting anyone do any less testing. Just the opposite; if we set things up properly with the STP, we might be able to run many more tests before each final release. - Dan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-04 19:09 ` Luigi Genoni 2001-11-05 1:51 ` Dan Kegel @ 2001-11-05 16:39 ` Timothy D. Witham 2001-11-12 6:24 ` Dan Kegel 2001-11-12 19:07 ` Timothy D. Witham 1 sibling, 2 replies; 18+ messages in thread From: Timothy D. Witham @ 2001-11-05 16:39 UTC (permalink / raw) To: Dan Kegel; +Cc: Luigi Genoni, Mike Galbraith, linux-kernel, stp On Sun, 2001-11-04 at 17:51, Dan Kegel wrote: > Luigi Genoni wrote: > > Problem is: > > there is a lot of HW out there, and we should ALL do stress tests, to have > > a wide basis for HWs and test cases. Basically it is very hard to agree > > about a set of stress tests, because we all have different needs, and our > > tests are based on our needs. That is a streght, because they tend to be > > real life tests. > I agree having the users run their applications and under their usage model is a very good way of testing code drops. Dan, I think that what you are trying to say is that it might be a good idea to take a group of tests and make them the standard set of "pass/fail" that people should look to before doing their own testing. > Sure, no argument there. > > > In my esperience, if some default set of tests comes out, then software > > tend to be optimized for this set. And that is badly wrong. > Any time you start optimizing for a set of performance tests you take the chance of doing things that only benefit the single test. The good part about open source is that if somebody tries to do that the rest of us can point out what a useless (or even counter productive) optimization they are trying to implement. Regression type pass/fail tests don't tend to have the benchmark optimization issue but like any test they usually only find the problems that you either already have had in the past or that are obvious. Not complete but they should be dynamic environment that things are being added to all the time. Also the nice part about a knows series of tests is that if a problem pops up it is much easier to reproduce for debugging purposes. > My post was motivated by two observations: > > 1. Alan Cox complains occasionally that Linus' trees are not well tested, > and can't survive the torture tests that the ac tree goes through before > release. (e.g. > "2.4.8-ac12 > I'm trying to make sure I can keep this testable > as 2.4.9 vanilla isnt being stable on my test sets " > > 2. The STP at OSDLab seems like a great resource that we might be able > to leverage to solve the problem Alan points out. > The nice part about the way that STP was designed is that it is extensible. If somebody comes up with another test we can add it. If we need to add additional equipment to get the run times down to a usable level then that is easy to do also. > I'm not suggesting anyone do any less testing. Just the opposite; > if we set things up properly with the STP, we might be able to run > many more tests before each final release. > We are in the process of setting up the Kernel STP to automatically grab the Linus and -ac kernels and run the full setup. This will do part of what Dan is asking for and it will also allow people who are looking to supply patches a baseline for there patch testing. Tim > - Dan > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Timothy D. Witham - Lab Director - wookie@osdlab.org Open Source Development Lab Inc - A non-profit corporation 15275 SW Koll Parkway - Suite H - Beaverton OR, 97006 (503)-626-2455 x11 (office) (503)-702-2871 (cell) (503)-626-2436 (fax) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-05 16:39 ` Timothy D. Witham @ 2001-11-12 6:24 ` Dan Kegel 2002-01-10 23:50 ` Daniel Phillips 2002-01-10 23:50 ` Daniel Phillips 2001-11-12 19:07 ` Timothy D. Witham 1 sibling, 2 replies; 18+ messages in thread From: Dan Kegel @ 2001-11-12 6:24 UTC (permalink / raw) To: Timothy D. Witham; +Cc: Luigi Genoni, Mike Galbraith, linux-kernel, stp "Timothy D. Witham" wrote: > ... > I agree having the users run their applications and under their usage > model is a very good way of testing code drops. Dan, I think that what > you are trying to say is that it might be a good idea to take a group > of tests and make them the standard set of "pass/fail" that people > should look to before doing their own testing. More like a safety net. It'd help make sure we didn't forget something obvious. >... > Regression type pass/fail tests don't tend to have the benchmark > optimization issue but like any test they usually only find the > problems that you either already have had in the past or that are > obvious. Not complete but they should be dynamic environment that > things are being added to all the time. Also the nice part about a > knows series of tests is that if a problem pops up it is much > easier to reproduce for debugging purposes. Yep. > > 2. The STP at OSDLab seems like a great resource that we might be able > > to leverage to solve the problem Alan points out. > > The nice part about the way that STP was designed is that it is > extensible. If somebody comes up with another test we can add it. > If we need to add additional equipment to get the run times down > to a usable level then that is easy to do also. > > > I'm not suggesting anyone do any less testing. Just the opposite; > > if we set things up properly with the STP, we might be able to run > > many more tests before each final release. > > We are in the process of setting up the Kernel STP to automatically > grab the Linus and -ac kernels and run the full setup. This will > do part of what Dan is asking for and it will also allow people who > are looking to supply patches a baseline for there patch testing. That's super! Thanks, Tim! At some point it might be nice to also use the STP to help speed gcc 3 development, too. (I personally am really looking forward to the day when I can use the same compiler for both c++ and kernel.) - Dan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-12 6:24 ` Dan Kegel @ 2002-01-10 23:50 ` Daniel Phillips 2002-01-12 0:04 ` M. Edward (Ed) Borasky 2002-01-10 23:50 ` Daniel Phillips 1 sibling, 1 reply; 18+ messages in thread From: Daniel Phillips @ 2002-01-10 23:50 UTC (permalink / raw) To: Dan Kegel, Timothy D. Witham Cc: Luigi Genoni, Mike Galbraith, linux-kernel, stp On November 12, 2001 07:24 am, Dan Kegel wrote: > At some point it might be nice to also use the STP to help > speed gcc 3 development, too. (I personally am really > looking forward to the day when I can use the same compiler > for both c++ and kernel.) You already can, at least I can because gcc3 builds recent kernels just fine. IOW, it works for me. Conservatively, it's good to keep the old compiler around (choose your poison) for those few apps that don't build with gcc, but I feel quite comfortable at the moment having gcc3 as my default. -- Daniel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2002-01-10 23:50 ` Daniel Phillips @ 2002-01-12 0:04 ` M. Edward (Ed) Borasky 2002-01-12 0:29 ` eddantes 2002-01-12 0:34 ` [OT] " Kurt Garloff 0 siblings, 2 replies; 18+ messages in thread From: M. Edward (Ed) Borasky @ 2002-01-12 0:04 UTC (permalink / raw) To: Daniel Phillips Cc: Dan Kegel, Timothy D. Witham, Luigi Genoni, Mike Galbraith, linux-kernel, stp On Fri, 11 Jan 2002, Daniel Phillips wrote: > On November 12, 2001 07:24 am, Dan Kegel wrote: > > At some point it might be nice to also use the STP to help speed gcc > > 3 development, too. (I personally am really looking forward to the > > day when I can use the same compiler for both c++ and kernel.) > > You already can, at least I can because gcc3 builds recent kernels > just fine. IOW, it works for me. Conservatively, it's good to keep > the old compiler around (choose your poison) for those few apps that > don't build with gcc, but I feel quite comfortable at the moment > having gcc3 as my default. One particular application for which gcc 3.x *and* gcc 2.96.x are seriously deficient, at least on Intel/AMD 32-bit systems, is the high-performance linear algebra library Atlas. As a result, *my* default for compiling numerical applications is the Atlas-recommended one, 2.95.3. For the kernel, I use whatever the Red Hat 7.2 default is. -- M. Edward Borasky znmeb@borasky-research.net The COUGAR Project http://www.borasky-research.com/Cougar.htm I brought my inner child to "Take Your Child To Work Day." ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2002-01-12 0:04 ` M. Edward (Ed) Borasky @ 2002-01-12 0:29 ` eddantes 2002-01-12 0:34 ` [OT] " Kurt Garloff 1 sibling, 0 replies; 18+ messages in thread From: eddantes @ 2002-01-12 0:29 UTC (permalink / raw) To: M. Edward (Ed) Borasky Cc: Daniel Phillips, Dan Kegel, Timothy D. Witham, Luigi Genoni, Mike Galbraith, linux-kernel, stp M. Edward (Ed) Borasky wrote: [snip] > One particular application for which gcc 3.x *and* gcc 2.96.x are > seriously deficient, at least on Intel/AMD 32-bit systems, is the > high-performance linear algebra library Atlas. As a result, *my* default > for compiling numerical applications is the Atlas-recommended one, > 2.95.3. For the kernel, I use whatever the Red Hat 7.2 default is. > Mmhh... Just remember gcc 2.96.x is NOT a regular gcc release, you can check at: http://www.gnu.org/software/gcc/releases.html AFAIK, it is a RH-hacked pre-3.0, which is probably not the best thing to use for anything. The 3.x series are know to generate pretty slow code, anyway. So I bet your experience is pretty normal. I still stick with 2.95.[34] for x86 kernel compile, although I'm using 3.0 for all purposes on Hitashi SH, as only gcc>=3.0 correctly supports the sh4. /dantes ^ permalink raw reply [flat|nested] 18+ messages in thread
* [OT] Re: Regression testing of 2.4.x before release? 2002-01-12 0:04 ` M. Edward (Ed) Borasky 2002-01-12 0:29 ` eddantes @ 2002-01-12 0:34 ` Kurt Garloff 1 sibling, 0 replies; 18+ messages in thread From: Kurt Garloff @ 2002-01-12 0:34 UTC (permalink / raw) To: M. Edward (Ed) Borasky Cc: Daniel Phillips, Dan Kegel, Timothy D. Witham, Luigi Genoni, Mike Galbraith, linux-kernel, stp [-- Attachment #1: Type: text/plain, Size: 1000 bytes --] Hi, On Fri, Jan 11, 2002 at 04:04:59PM -0800, M. Edward (Ed) Borasky wrote: > One particular application for which gcc 3.x *and* gcc 2.96.x are > seriously deficient, at least on Intel/AMD 32-bit systems, is the > high-performance linear algebra library Atlas. As a result, *my* default > for compiling numerical applications is the Atlas-recommended one, > 2.95.3. For the kernel, I use whatever the Red Hat 7.2 default is. One of the problems of gcc-3 is taking decisions when to inline and when not. This can hurt numerical code a lot, especially C++. You may want to use -finline-limit-XXX to tune. http://www.garloff.de/kurt/freesoft/gcc/ v1 of my patch went into 3.0.3, some version (don't know which) into mainline, so 3.0.3 should do better. Regards, -- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, DE SCSI, Security [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-12 6:24 ` Dan Kegel 2002-01-10 23:50 ` Daniel Phillips @ 2002-01-10 23:50 ` Daniel Phillips 1 sibling, 0 replies; 18+ messages in thread From: Daniel Phillips @ 2002-01-10 23:50 UTC (permalink / raw) To: Dan Kegel, Timothy D. Witham Cc: Luigi Genoni, Mike Galbraith, linux-kernel, stp On November 12, 2001 07:24 am, Dan Kegel wrote: > At some point it might be nice to also use the STP to help > speed gcc 3 development, too. (I personally am really > looking forward to the day when I can use the same compiler > for both c++ and kernel.) You already can, at least I can because gcc3 builds recent kernels just fine. IOW, it works for me. Conservatively, it's good to keep the old compiler around (choose your poison) for those few apps that don't build with gcc, but I feel quite comfortable at the moment having gcc3 as my default. -- Daniel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-05 16:39 ` Timothy D. Witham 2001-11-12 6:24 ` Dan Kegel @ 2001-11-12 19:07 ` Timothy D. Witham 2001-11-13 4:53 ` Dan Kegel 1 sibling, 1 reply; 18+ messages in thread From: Timothy D. Witham @ 2001-11-12 19:07 UTC (permalink / raw) To: Dan Kegel; +Cc: Luigi Genoni, Mike Galbraith, linux-kernel, stp On Sun, 2001-11-11 at 22:24, Dan Kegel wrote: > "Timothy D. Witham" wrote: Snip > > At some point it might be nice to also use the STP to help > speed gcc 3 development, too. (I personally am really > looking forward to the day when I can use the same compiler > for both c++ and kernel.) > Strange, I was just talking to somebody about compiler performance and regression issues and what sort of automation could be done to do that sort of testing. Since the STP is really a framework and just about any piece of software and testing environment could be worked into it. So I guess you could have two pieces. One that just ran a bunch of compile and user level tests and then one that went in and checked out the compiler on a kernel tree and then ran the same performance tests that had been run using the "standard" compiler. Are you stepping forward to integrate this into STP? :-) > - Dan -- Timothy D. Witham - Lab Director - wookie@osdlab.org Open Source Development Lab Inc - A non-profit corporation 15275 SW Koll Parkway - Suite H - Beaverton OR, 97006 (503)-626-2455 x11 (office) (503)-702-2871 (cell) (503)-626-2436 (fax) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-12 19:07 ` Timothy D. Witham @ 2001-11-13 4:53 ` Dan Kegel 2001-11-13 22:00 ` STP for automated GCC testing (was Re: Regression testing of 2.4.x beforerelease?) Bryce Harrington 0 siblings, 1 reply; 18+ messages in thread From: Dan Kegel @ 2001-11-13 4:53 UTC (permalink / raw) To: Timothy D. Witham; +Cc: Luigi Genoni, Mike Galbraith, linux-kernel, stp "Timothy D. Witham" wrote: > > On Sun, 2001-11-11 at 22:24, Dan Kegel wrote: > > At some point it might be nice to also use the STP to help > > speed gcc 3 development, too. (I personally am really > > looking forward to the day when I can use the same compiler > > for both c++ and kernel.) > > Strange, I was just talking to somebody about compiler > performance and regression issues and what sort of automation > could be done to do that sort of testing. > > Since the STP is really a framework and just about any piece > of software and testing environment could be worked into it. > > So I guess you could have two pieces. One that just ran a bunch > of compile and user level tests and then one that went in and > checked out the compiler on a kernel tree and then ran the > same performance tests that had been run using the "standard" > compiler. Go/no-go tests, where you make sure a kernel compiled with gcc 3 actually works, might be appropriate for starters. I don't know if that's been established yet. > Are you stepping forward to integrate this into STP? :-) I wish! Alas, tendinitis makes hacking hazardous for me for now. - Dan ^ permalink raw reply [flat|nested] 18+ messages in thread
* STP for automated GCC testing (was Re: Regression testing of 2.4.x beforerelease?) 2001-11-13 4:53 ` Dan Kegel @ 2001-11-13 22:00 ` Bryce Harrington 0 siblings, 0 replies; 18+ messages in thread From: Bryce Harrington @ 2001-11-13 22:00 UTC (permalink / raw) To: Dan Kegel Cc: Timothy D. Witham, Luigi Genoni, Mike Galbraith, linux-kernel, stp On Mon, 12 Nov 2001, Dan Kegel wrote: > "Timothy D. Witham" wrote: > > > > On Sun, 2001-11-11 at 22:24, Dan Kegel wrote: > > > At some point it might be nice to also use the STP to help > > > speed gcc 3 development, too. (I personally am really > > > looking forward to the day when I can use the same compiler > > > for both c++ and kernel.) > > > > Strange, I was just talking to somebody about compiler > > performance and regression issues and what sort of automation > > could be done to do that sort of testing. > > > > Since the STP is really a framework and just about any piece > > of software and testing environment could be worked into it. > > > > So I guess you could have two pieces. One that just ran a bunch > > of compile and user level tests and then one that went in and > > checked out the compiler on a kernel tree and then ran the > > same performance tests that had been run using the "standard" > > compiler. > > Go/no-go tests, where you make sure a kernel compiled with gcc 3 > actually works, might be appropriate for starters. I don't know > if that's been established yet. > > > Are you stepping forward to integrate this into STP? :-) > > I wish! Alas, tendinitis makes hacking hazardous for me for now. > Dan, I'd be willing to join in with some of the hacking. I helped develop STP so am familiar with how it works and how to apply it to this. I've used/compiled/cursed at gcc for years but am not super familiar with its internals, so would welcome some advice and help there. Would anyone else be interested in joining in on doing this? I think providing this testing service for gcc would be invaluable for the community. Basically we need a couple folks with perl scripting and html form creation skills. Anyway, if I get a few positive responses and it's okay by Tim, I'll go ahead and get a mailing list, etc. set up for everyone interested in joining in on this. Bryce ^ permalink raw reply [flat|nested] 18+ messages in thread
* Regression testing of 2.4.x before release? @ 2001-11-04 7:03 Dan Kegel 2001-11-04 7:15 ` Ted Deppner 0 siblings, 1 reply; 18+ messages in thread From: Dan Kegel @ 2001-11-04 7:03 UTC (permalink / raw) To: linux-kernel I get the impression that Alan stress-tests his kernels more than Linus does before releasing them. Would it be a Good Thing if Linus decided to make sure his kernels pass all of Alan's stress tests before releasing them? (I'm talking e.g. 2.4.14-final, not 2.4.14-preX.) - Dan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-04 7:03 Regression testing of 2.4.x before release? Dan Kegel @ 2001-11-04 7:15 ` Ted Deppner 2001-11-04 12:04 ` Tahar 0 siblings, 1 reply; 18+ messages in thread From: Ted Deppner @ 2001-11-04 7:15 UTC (permalink / raw) To: Dan Kegel; +Cc: linux-kernel On Sat, Nov 03, 2001 at 11:03:17PM -0800, Dan Kegel wrote: > Would it be a Good Thing if Linus decided to make sure > his kernels pass all of Alan's stress tests before > releasing them? (I'm talking e.g. 2.4.14-final, not 2.4.14-preX.) Yes it would. It would be a better idea if everyone (including you and me) stress test those pre and final kernels too. -- Ted Deppner http://www.psyber.com/~ted/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-04 7:15 ` Ted Deppner @ 2001-11-04 12:04 ` Tahar 2001-11-04 17:27 ` Ted Deppner 2001-11-04 18:41 ` Luigi Genoni 0 siblings, 2 replies; 18+ messages in thread From: Tahar @ 2001-11-04 12:04 UTC (permalink / raw) To: Ted Deppner; +Cc: Dan Kegel, linux-kernel > Yes it would. It would be a better idea if everyone (including you and > me) stress test those pre and final kernels too. Just a newbie question: where can we find such stress tests, and what are the kernel parts targeted by these tests ? Thanks, Tahar ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-04 12:04 ` Tahar @ 2001-11-04 17:27 ` Ted Deppner 2001-11-04 18:41 ` Luigi Genoni 1 sibling, 0 replies; 18+ messages in thread From: Ted Deppner @ 2001-11-04 17:27 UTC (permalink / raw) To: jarboui; +Cc: linux-kernel On Sun, Nov 04, 2001 at 01:04:27PM +0100, Tahar wrote: > Just a newbie question: where can we find such stress tests, and what > are the kernel parts targeted by these tests ? A few searches for "linux benchmark", "unix benchmark", or perhaps just "benchmark" on Google and Freshmeat.net should turn up plenty to keep you busy. Linus and others have said in the past thought, that YOUR usage is the testing they want... So it's best if you install the kernel and use it normally, whatever you'd use a kernel to do. I am concerned about lots of I/O and multiprocessing... So I test by doing CD-RW burns to two drives (12x and a 4x), NFS data moves (using bonnie, dd, and cat), while listening to MP3 streams, reading my email, and watching extace, with some of my mysql data loading scripts running. These are all things I do normally, and I'm the best able to compare new performance to past performance. Sure, I don't do all of those things all at the same time _usually_, but that's the main body of my 'test bench'. -- Ted Deppner http://www.psyber.com/~ted/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression testing of 2.4.x before release? 2001-11-04 12:04 ` Tahar 2001-11-04 17:27 ` Ted Deppner @ 2001-11-04 18:41 ` Luigi Genoni 1 sibling, 0 replies; 18+ messages in thread From: Luigi Genoni @ 2001-11-04 18:41 UTC (permalink / raw) To: jarboui; +Cc: Ted Deppner, Dan Kegel, linux-kernel Most of us just developed their own stress test, depending on what they do need. Then many use dbench, cerberus and so on. I would suggest you to start with cerberus. Luigi On Sun, 4 Nov 2001, Tahar wrote: > > > Yes it would. It would be a better idea if everyone (including you and > > me) stress test those pre and final kernels too. > > Just a newbie question: where can we find such stress tests, and what > are the kernel parts targeted by these tests ? > > Thanks, > > Tahar > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2002-01-14 4:50 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <Pine.LNX.4.33.0111040832060.364-100000@mikeg.weiden.de> 2001-11-04 17:58 ` Regression testing of 2.4.x before release? Dan Kegel 2001-11-04 19:09 ` Luigi Genoni 2001-11-05 1:51 ` Dan Kegel 2001-11-05 16:39 ` Timothy D. Witham 2001-11-12 6:24 ` Dan Kegel 2002-01-10 23:50 ` Daniel Phillips 2002-01-12 0:04 ` M. Edward (Ed) Borasky 2002-01-12 0:29 ` eddantes 2002-01-12 0:34 ` [OT] " Kurt Garloff 2002-01-10 23:50 ` Daniel Phillips 2001-11-12 19:07 ` Timothy D. Witham 2001-11-13 4:53 ` Dan Kegel 2001-11-13 22:00 ` STP for automated GCC testing (was Re: Regression testing of 2.4.x beforerelease?) Bryce Harrington 2001-11-04 7:03 Regression testing of 2.4.x before release? Dan Kegel 2001-11-04 7:15 ` Ted Deppner 2001-11-04 12:04 ` Tahar 2001-11-04 17:27 ` Ted Deppner 2001-11-04 18:41 ` Luigi Genoni
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).