Testing for kernel performance regressions
Testing for kernel performance regressions
Posted Aug 4, 2012 21:47 UTC (Sat) by mikov (guest, #33179)In reply to: Testing for kernel performance regressions by gregkh
Parent article: Testing for kernel performance regressions
- there is no static set of hardware that I use. You can't buy the same hardware even if you wanted to. So, I would have to be testing all the time. Considering that the kernel changes all the time...
- Should I be testing my distro's kernel or the latest mainline? If the latter, why am I testing a kernel I am not going to use for years, if at all?
- where do I even report the bugs? Lkml? Bugzilla? My distro?
In reality, it would be a full time job for a couple of people to deal with all this. Highly paid jobs. Not every business can afford that.
A stable source level API would go a long way towards improving the situation, but that is not likely to happen :-)
Posted Aug 4, 2012 22:11 UTC (Sat)
by dlang (guest, #313)
[Link]
you should test the mainline kernel because your distro is going to be based off of the mainline. It's because your distro is based off the mainline that you should test it.
You don't have to test every -rc kernel, but the more testing that you do, the less likely you are to run into problems when you upgrade to the latest release of your distro.
If you test only when your distro upgrades their kernel every 5 years, then finding where in the 5 years of development things went wrong is an impossible task
If you test the released kernels every 3 months, there's only 3 months of work to go through.
If you test each kernel release around the -rc3-5 range, you are even better off as the developers are currently thinking about that release, and looking for problems to fix.
> - where do I even report the bugs? Lkml? Bugzilla? My distro?
That's easy, if you are testing a mainline kernel, LKML is the best place to report bugs.
Testing for kernel performance regressions