This PR is only being used to measure ci runtime differences.
The addrman_serdeser target is slow under valgrind and msan instrumentation. It takes the majority of the ~1 hour runtime on its own. Exclude it from these jobs to reduce runtime.
It is still run in native_fuzz (“fuzzer,address,undefined,integer”), only without instrumentation.
The addrman_serdeser target is slow under valgrind and msan
instrumentation. It takes the majority of the ~1 hour runtime on its
own. Exclude it from these jobs to reduce runtime.
It is still run in native_fuzz ("fuzzer,address,undefined,integer"),
only without instrumentation.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
See the guideline for information on the review process. A summary of reviews will appear here.
Not sure. If the CI task is run, but skips a specific part, we’ll eventually see bugs in that part. (Similar to how some bench tests were never run and then they degraded)
Part of this will fix itself in a few weeks before branch-off, when the fuzz inputs are pruned.
If that isn’t enough, the fuzz target itself can be evaluated if it has useful coverage, and if the search space can be reduced without hurting read-world coverage.
Other than that, if the fuzz target only has real-world coverage, it seems good to run it, even if it takes long.
Not sure. If the CI task is run, but skips a specific part, we’ll eventually see bugs in that part. (Similar to how some bench tests were never run and then they degraded)
That’s fair enough.
Part of this will fix itself in a few weeks before branch-off, when the fuzz inputs are pruned.
I was going to ask about pruning the inputs, as this target has many of them, though not quite the largest, as I don’t know how/when we do that…
If that isn’t enough, the fuzz target itself can be evaluated if it has useful coverage, and if the search space can be reduced without hurting read-world coverage.
👍🏼
Other than that, if the fuzz target only has real-world coverage, it seems good to run it, even if it takes long.
Yeah I agree with this. I am still curious to see how much impact this has though. When I was running ~ this configuration locally, all targets completed in about < 14 minutes, then I spent > 1hour on a single core waiting for this one target to complete… Just unfortunate to have to tie up 1 md and 1 lg runner i.e. 22 “cores” worth of runners for so long, doing little work.
It does indeed appear to knock off 20 mins from valgrind-fuzz, but msan-fuzz still slow due to ephemeral_package_eval target.
If we weren’t planning on dropping valgrind-fuzz, I’d perhaps suggest removing ephemeral_package_eval from the msan job (keep it in valgrind fuzz), and remove addrman_serdeser from valgrind fuzz (keep it in msan fuzz).
But will shelve this experiment for now, pending the outcome of #34492
Part of this will fix itself in a few weeks before branch-off, when the fuzz inputs are pruned.
I was going to ask about pruning the inputs, as this target has many of them, though not quite the largest, as I don’t know how/when we do that…
The docs are in https://github.com/bitcoin-core/qa-assets?tab=readme-ov-file#pruning-inputs
Labels
Tests