Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: tweak weekly tests #1934

Merged
merged 6 commits into from
Mar 27, 2025
Merged

feat: tweak weekly tests #1934

merged 6 commits into from
Mar 27, 2025

Conversation

DavePearce
Copy link
Collaborator

@DavePearce DavePearce commented Mar 20, 2025

Ready to merge.

@DavePearce DavePearce force-pushed the 1932-feat-tweak-weekly-tests branch 28 times, most recently from 2630105 to ef72a69 Compare March 25, 2025 01:53
@DavePearce DavePearce requested a review from amkCha March 25, 2025 01:53
@DavePearce DavePearce force-pushed the 1932-feat-tweak-weekly-tests branch from ef72a69 to 36c65d9 Compare March 25, 2025 01:55
@DavePearce DavePearce force-pushed the 1932-feat-tweak-weekly-tests branch 2 times, most recently from 79aa6ae to dbb8a1d Compare March 25, 2025 03:49
@DavePearce DavePearce force-pushed the 1932-feat-tweak-weekly-tests branch 2 times, most recently from 1793872 to 7b5ded0 Compare March 25, 2025 21:37
Since the precompile call tests have a different dynamic from other
weekly tests, have moved all of them into the group that was previously
the weekly ecpairing suite.  That way, the parallelism for this group
can be dramatically increased without causing other (costly and
unrelated) weekly tests from failing.
The purpose of this is just for testing to let me run the workflow prior
to it being merged in (since it hasn't been run before).
The challenge with using a high level of parallelism is that we end up
creating a large number of JVMs.  With a minimum heap size of 4GB, we
completely max out memory at 32 processes.  That's ignoring memory
required for the OS and/or go-corset itself.

However, most of these short-lived tests do not need anything like 4GB
to complete.  Setting a minimum heap size of 512MB means the average
test consumes much less RAM, whilst keeping the maximum heap size at 8GB
means there is room for them to expand as needed.

The final challenge with increasing the degree of parallelism is
go-corset itself.  This also uses a large number of cores, even for a
single test.  Therefore, there is a careful balance needed to make
effective use of all available cores.
This enables random sampling using the day of the month as a seed for
the RNG.  This means that, in principle, we can recreate any failures by
looking up on which day the test failed.  At the same time, we benefit
from wider testing over a period of time.

A default sample size is given individually for each test, and this can
be overridden using a single environment variable
PRC_CALLTESTS_SAMPLE_SIZE.  Hopefully, this provides the level of
flexibility needed.
This consolidates all of the prcCallTests into the existing weeklyTests
group.  This makes sense as they all have roughly similar test profiles.
The weeklyTests now has a much more aggressive degree of parallelism.

In addition, this sets more suitable default sample sizes for the PRC
calltests.  Specifically, defaults are set to approx 10% of the overall
parameter space.
@DavePearce DavePearce force-pushed the 1932-feat-tweak-weekly-tests branch 2 times, most recently from 3d3b7a6 to f97b137 Compare March 26, 2025 20:11
This splits the weekly tests up into two distinct jobs so they can run
in parallel.  This hopefully should allow for a larger sampling size.
@DavePearce DavePearce force-pushed the 1932-feat-tweak-weekly-tests branch from f97b137 to 757b3f8 Compare March 26, 2025 22:23
@DavePearce DavePearce merged commit 024a763 into arith-dev Mar 27, 2025
8 of 9 checks passed
@DavePearce DavePearce deleted the 1932-feat-tweak-weekly-tests branch March 27, 2025 02:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants