diff mbox

kselftest/timers: Set default threadtest values to simplify execution scripts

Message ID 1426693913-5738-1-git-send-email-john.stultz@linaro.org
State New
Headers show

Commit Message

John Stultz March 18, 2015, 3:51 p.m. UTC
In order to keep the kselftest Makefiles simpler, set the threadtest
default values to the ones used in standard run_tests

Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
 tools/testing/selftests/timers/threadtest.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

Comments

John Stultz March 19, 2015, 10:34 p.m. UTC | #1
On Thu, Mar 19, 2015 at 3:01 PM, Shuah Khan <shuahkh@osg.samsung.com> wrote:
> On 03/18/2015 09:51 AM, John Stultz wrote:
>> In order to keep the kselftest Makefiles simpler, set the threadtest
>> default values to the ones used in standard run_tests
>>
>> Cc: Shuah Khan <shuahkh@osg.samsung.com>
>> Cc: Prarit Bhargava <prarit@redhat.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Richard Cochran <richardcochran@gmail.com>
>> Signed-off-by: John Stultz <john.stultz@linaro.org>
>> ---
>>  tools/testing/selftests/timers/threadtest.c | 8 ++++++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>
> Applied to next for 4.1
>
> Some numbers for you with timer tests included:
>
> make kselftest target takes:
>
> real    11m50.499s
> user    3m25.979s
> sys     5m45.433s
>
> It is creeping up, previous timing was
>
> real 9.41
> user 3.55
> system 0:24.86
>
> Not concerned yet. Might be getting closer to
> needing to defining quick vs long test categories.

Yea, the timekeeping tests are particularly rough about how long the
run. In some cases we're having to watch for behavior that could be
somewhat rare, so we need to watch for a fair amount of time.  In some
cases we're doing our own calibrations which require a larger amount
of time to ensure accuracy. And in other cases, we want to have timers
that fire far enough out that any scheduler variance/noise is easy to
filter out.

With the destructive tests, which re-run the validation tests
repeatedly under different conditions, it ends up being about an hour!
So I feel this pain.

But there's also probably some spots where 3 seconds seemed like a
good value, but could be shorter.  So I'll have to take another look
to see if we could reasonably compress some of the intervals we use
down. There may also be some spots where we could parallelize the
tests across the various clockids.

thanks
-john
--
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/
diff mbox

Patch

diff --git a/tools/testing/selftests/timers/threadtest.c b/tools/testing/selftests/timers/threadtest.c
index facd889..e632e11 100644
--- a/tools/testing/selftests/timers/threadtest.c
+++ b/tools/testing/selftests/timers/threadtest.c
@@ -126,11 +126,13 @@  void *independent_thread(void *arg)
 	return NULL;
 }
 
+#define DEFAULT_THREAD_COUNT 8
+#define DEFAULT_RUNTIME 30
 
 int main(int argc, char **argv)
 {
-	int thread_count = 1, i;
-	time_t start, now, runtime = 60;
+	int thread_count, i;
+	time_t start, now, runtime;
 	char buf[255];
 	pthread_t pth[MAX_THREADS];
 	int opt;
@@ -138,6 +140,8 @@  int main(int argc, char **argv)
 	int ret = 0;
 	void *(*thread)(void *) = shared_thread;
 
+	thread_count = DEFAULT_THREAD_COUNT;
+	runtime = DEFAULT_RUNTIME;
 
 	/* Process arguments */
 	while ((opt = getopt(argc, argv, "t:n:i")) != -1) {