If this is about frysk.proc.TestBreakpoints then a big chunk of the slowdown
comes from the stepping/breakpointing testing. At the moment the
funit-breakpoints contains a workaround to reset the signal handler (see bug
#3997) with that removed they are a lot faster. They also do 7 iterations over
all the different breakpoints. This could be reduced to 3 in case of stepping.
Stepping a program is however slow whatever you do.

What is "slow" and what is "acceptable" in this case?

The test should execute in something less than a second(In reply to comment #1)
> If this is about frysk.proc.TestBreakpoints then a big chunk of the slowdown
> comes from the stepping/breakpointing testing. At the moment the
> funit-breakpoints contains a workaround to reset the signal handler (see bug
> #3997) with that removed they are a lot faster. They also do 7 iterations over
> all the different breakpoints. This could be reduced to 3 in case of stepping.
> Stepping a program is however slow whatever you do.

Yes, stepping is slow, however it should still be possible for each test to
complete in something less than a second.  Could those tests be stepping 10 000s
of instructions, or contain a polling wait, or contain unnecessary repetition?

For the kernel bug, please remove the workaround and instead mark the test up as
broken on that system - add a TestCase.broken<whatever>XXX method that keys off
the kernel, there's an existing example.

If the test is looking for races using repetition, then a Stress*.java test is
better.  Once the race is identified it can be turned into a more deterministic
and faster Test*.java.

All tests now finish in 1 or 2 seconds.

2007-02-08  Mark Wielaard  <mark@klomp.org>

       * TestBreakpoint.java: Lower interations from 7 to 3.

2007-02-09  Mark Wielaard  <mark@klomp.org>

       * funit-breakpoints.c (signal_handler):
       Remove bogus signal reset kernel workaround.

No TestCase.broken<whatever>XXX was added for now since there is no good feature
test for this kernel bug. The frysk-imports/tests will fail however and this
test will never be reached on broken systems with a make check.

(In reply to comment #3)

> No TestCase.broken<whatever>XXX was added for now since there is no good feature
> test for this kernel bug. The frysk-imports/tests will fail however and this
> test will never be reached on broken systems with a make check.

Both << make -k >>  and ./frysk-core/TestRunner are both very common, so the
test can't rely no not being run.

frysk.junit.TestCase contains:

    protected static boolean brokenUtraceXXX (int bug)
    {
        if (uname == null)
            uname = Uname.get ();
        String[] badKernels = {
            "2.6.18-1.2849.fc6",
            "2.6.18-1.2239.fc5"
        };
        for (int i = 0; i < badKernels.length; i++) {
            if (badKernels[i].equals (uname.getRelease ()))
                return brokenXXX (bug);
        }
        return false;
    }

so something similar would be sufficient.

I'm pretty sure the tests can be sped up to < 1 second.

I checked this in, frysk-core on fc5 results are consistent again.

Index: frysk-core/frysk/proc/ChangeLog
2007-02-09  Andrew Cagney  <cagney@redhat.com>

        * TestProcStopped.java: Replace brokenUtraceXXX with
        brokenIfUtraceXXX.
        * TestTaskTerminateObserver.java: Ditto.
        * TestProcTasksObserver.java: Ditto.
        * TestRefresh.java (testRefreshZombie): Use brokenIfKernelXXX.
        * TestBreakpoints.java (brokenSignals): New.
        (testSteppingtestHitAndRun, testSteppingtestInsertRemove)
        (testSteppingAddLots): Call brokenSignals.

Index: frysk-imports/frysk/junit/ChangeLog
2007-02-09  Andrew Cagney  <cagney@redhat.com>

        * TestCase.java (brokenIfKernelXXX): New method.
        (brokenIfUtraceXXX): Rename brokenUtraceXXX.  Use
        brokenIfKernelXXX.