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

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

[John Stultz]

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(-)

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) {
-- 
1.9.1

Re: [PATCH] kselftest/timers: Set default threadtest values to simplify execution scripts

[Shuah Khan]

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.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978

Re: [PATCH] kselftest/timers: Set default threadtest values to simplify execution scripts

[John Stultz]

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

Re: [PATCH] kselftest/timers: Set default threadtest values to simplify execution scripts

[Shuah Khan]

On 03/19/2015 04:34 PM, John Stultz wrote:
> 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.
> 

If you can take a look to see which tests can be included in a
quick test run vs. longer test run in addition to destructive
vs. normal. I will work on adding categories soon. The logic
can be isolated in selftest/Makefile and timers/Makefile.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978