stdlib: Tune down fork arc4random tests
Checks
Context |
Check |
Description |
redhat-pt-bot/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
redhat-pt-bot/TryBot-32bit |
success
|
Build for i686
|
linaro-tcwg-bot/tcwg_glibc_build--master-arm |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 |
pending
|
Patch applied
|
linaro-tcwg-bot/tcwg_glibc_check--master-arm |
success
|
Testing passed
|
Commit Message
There is no fork detection on current arc4random implementation, so
use lower subprocess on fork tests. The tests now run on 0.1s
instead of 8s on a Ryzen9 5900X.
Checked on x86_64-linux-gnu.
---
stdlib/tst-arc4random-fork.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
Comments
On 6/1/23 11:59, Adhemerval Zanella via Libc-alpha wrote:
> There is no fork detection on current arc4random implementation, so
> use lower subprocess on fork tests. The tests now run on 0.1s
> instead of 8s on a Ryzen9 5900X.
Agreed.
LGTM.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
> Checked on x86_64-linux-gnu.
> ---
> stdlib/tst-arc4random-fork.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/stdlib/tst-arc4random-fork.c b/stdlib/tst-arc4random-fork.c
> index a69ec3968f..65d5893f5e 100644
> --- a/stdlib/tst-arc4random-fork.c
> +++ b/stdlib/tst-arc4random-fork.c
> @@ -30,14 +30,10 @@
> #include <unistd.h>
>
> /* Perform multiple runs. The subsequent runs start with an
> - already-initialized random number generator. (The number 1500 was
> - seen to reproduce failures reliable in case of a race condition in
> - the fork detection code.) */
> -enum { runs = 1500 };
> -
> -/* One hundred processes in total. This should be high enough to
> - expose any issues, but low enough not to tax the overall system too
> - much. */
> + already-initialized random number generator. */
> +enum { runs = 10 };
> +
> +/* Total number of spawned processes on each run. */
> enum { subprocesses = 49 };
OK.
>
> /* The total number of processes. */
On Thu, 2023-06-01 at 12:59 -0300, Adhemerval Zanella via Libc-alpha
wrote:
> There is no fork detection on current arc4random implementation, so
> use lower subprocess on fork tests. The tests now run on 0.1s
> instead of 8s on a Ryzen9 5900X.
>
> Checked on x86_64-linux-gnu.
This also fixed the last (timeout) issue on the glibc-fedora-arm64
builder:
https://builder.sourceware.org/buildbot/#/builders/glibc-fedora-arm64
Finally all green \o/
4635 PASS
38 UNSUPPORTED
16 XFAIL
Thanks,
Mark
@@ -30,14 +30,10 @@
#include <unistd.h>
/* Perform multiple runs. The subsequent runs start with an
- already-initialized random number generator. (The number 1500 was
- seen to reproduce failures reliable in case of a race condition in
- the fork detection code.) */
-enum { runs = 1500 };
-
-/* One hundred processes in total. This should be high enough to
- expose any issues, but low enough not to tax the overall system too
- much. */
+ already-initialized random number generator. */
+enum { runs = 10 };
+
+/* Total number of spawned processes on each run. */
enum { subprocesses = 49 };
/* The total number of processes. */