[opensuse-factory] openqa kernel testing
Hello, All. Will we be able to add some kernel performance tests? Especially, filesystem and io schedulers ones. Last year I had an issue when my system having been upgraded to 12.3 was becoming unusable due to deadlock in reiserfs quota routines within 5 minutes after boot. Majority of processes just were in d state. Would be great to have an automatic tool to avoid similar issues in futute. -- Best regards! Posted using Hotdoged on Android -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06.02.2014 07:15, Matwey Kornilov wrote:
Hello, All.
Will we be able to add some kernel performance tests? Especially, filesystem and io schedulers ones.
Last year I had an issue when my system having been upgraded to 12.3 was becoming unusable due to deadlock in reiserfs quota routines within 5 minutes after boot. Majority of processes just were in d state.
Would be great to have an automatic tool to avoid similar issues in futute.
You can do a lot of things with automated tests, but I think it's unreasonable to expect someone (else) to write a test case for reiserfs quota. But enabling interested people to (easily) write test cases is a mid term goal. Which of them we want to run and when is another discussion. Test suites can be quite unfair to the one looking at them - you have to often dig if the test is broken or the software you're testing. This is especially true for performance tests. So this needs to be done with extra care. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Stephan Kulow <coolo@suse.de>:
On 06.02.2014 07:15, Matwey Kornilov wrote:
Hello, All.
Will we be able to add some kernel performance tests? Especially, filesystem and io schedulers ones.
Last year I had an issue when my system having been upgraded to 12.3 was becoming unusable due to deadlock in reiserfs quota routines within 5 minutes after boot. Majority of processes just were in d state.
Would be great to have an automatic tool to avoid similar issues in futute.
You can do a lot of things with automated tests, but I think it's unreasonable to expect someone (else) to write a test case for reiserfs quota.
But enabling interested people to (easily) write test cases is a mid term goal. Which of them we want to run and when is another discussion. Test suites can be quite unfair to the one looking at them - you have to often dig if the test is broken or the software you're testing. This is especially true for performance tests. So this needs to be done with extra care.
Also performance test can be tricky in a KVM environment where there are many other instances running at the same time. But I am sure that the use case expressed by Matwey (detecting regressions in the performance) is something that can be done until some extend.
Greetings, Stephan
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 02/06/2014 01:02 PM, Alberto Planas Dominguez wrote:
Also performance test can be tricky in a KVM environment where there are many other instances running at the same time.
true - I can second that: Sometimes I'm experiencing false positives of a disk-intense test case in the coreutils-testsuite package: once in a while it just takes 60-70s instead of ~30s as usual (... and this with 'make -j1'). ;-/ Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
06.02.2014 15:48, Stephan Kulow пишет:
On 06.02.2014 07:15, Matwey Kornilov wrote: You can do a lot of things with automated tests, but I think it's unreasonable to expect someone (else) to write a test case for reiserfs quota.
But enabling interested people to (easily) write test cases is a mid term goal. Which of them we want to run and when is another discussion. Test suites can be quite unfair to the one looking at them - you have to often dig if the test is broken or the software you're testing. This is especially true for performance tests. So this needs to be done with extra care.
Greetings, Stephan
Ok, I see. If it were relatively easy I would try to make a couple of tests. The question is not about reiser only, but about each filesystem or storage subsystem. Unfortunately, things like this happen sometimes: http://lists.opensuse.org/opensuse-factory/2014-01/msg00294.html I don't like when release eats my data or crash my kernel. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06.02.2014 16:33, Matwey V. Kornilov wrote:
The question is not about reiser only, but about each filesystem or storage subsystem. Unfortunately, things like this happen sometimes: http://lists.opensuse.org/opensuse-factory/2014-01/msg00294.html
I don't like when release eats my data or crash my kernel.
I don't think there are many who like that. The problem is you can only test what you expect to fail. And especially hardware specific things are tricky to catch - as we test on one single hardware: QEMU. For actual milestones we can concentrate on more testing, but for staging to work, the testing needs to be fast enough not to become a problem. And creating the test DVD is easily a day already. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Alberto Planas Dominguez
-
Bernhard Voelker
-
Matwey Kornilov
-
Matwey V. Kornilov
-
Stephan Kulow