[PATCH] test-memcpy.c: Double TIMEOUT to (8 * 60)
Adhemerval Zanella
adhemerval.zanella@linaro.org
Mon Nov 8 19:46:29 GMT 2021
On 08/11/2021 16:43, Noah Goldstein wrote:
> On Mon, Nov 8, 2021 at 8:02 AM Noah Goldstein <goldstein.w.n@gmail.com> wrote:
>>
>> On Mon, Nov 8, 2021 at 7:14 AM H.J. Lu via Libc-alpha
>> <libc-alpha@sourceware.org> wrote:
>>>
>>> On Mon, Nov 8, 2021 at 3:39 AM Adhemerval Zanella
>>> <adhemerval.zanella@linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 07/11/2021 13:08, H.J. Lu via Libc-alpha wrote:
>>>>> commit d585ba47fcda99fdf228e3e45a01b11a15efbc5a
>>>>> Author: Noah Goldstein <goldstein.w.n@gmail.com>
>>>>> Date: Mon Nov 1 00:49:48 2021 -0500
>>>>>
>>>>> string: Make tests birdirectional test-memcpy.c
>>>>>
>>>>> This commit updates the memcpy tests to test both dst > src and dst <
>>>>> src. This is because there is logic in the code based on the
>>>>>
>>>>> Signed-off-by: Noah Goldstein <goldstein.w.n@gmail.com>
>>>>> Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
>>>>>
>>>>> significantly increased the number of tests. On Intel Core i7-1165G7,
>>>>> test-memcpy takes 120 seconds to run when machine is idle. Double
>>>>> TIMEOUT to (8 * 60) for test-memcpy to avoid timeout when machine is
>>>>> under heavy load.
>>>>
>>>> Shouldn't we split the test instead? If it takes 120s on a high-end chip,
>>>> it might take way more in other chips. It also optimizes the testsuite,
>>>> since it would allow to better use parallel builds.
>>>
>>> This sounds like a good idea. Noah, can you do that?
>
> The reality is 95% of the extra test time is from the additional large
> memcpy tests in `#ifdef DO_EXTRA_TESTS` region. Not sure
> there is really any value in making a seperate test for them as
> I think the runtime would still require the larger timeout.
>
> Do we still want it? Alternatively I could cut out some of the tests.
Maybe spawn multiple processes to cover different sizes within the loop
(something analogous to #omp for)?
More information about the Libc-alpha
mailing list