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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Mar 2015 15:34:25 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Shuah Khan <shuahkh@....samsung.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Prarit Bhargava <prarit@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH] kselftest/timers: Set default threadtest values to
 simplify execution scripts

On Thu, Mar 19, 2015 at 3:01 PM, Shuah Khan <shuahkh@....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@....samsung.com>
>> Cc: Prarit Bhargava <prarit@...hat.com>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Cc: Richard Cochran <richardcochran@...il.com>
>> Signed-off-by: John Stultz <john.stultz@...aro.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/