RFR: 8316142: Enable parallelism in vmTestbase/nsk/monitoring/stress/lowmem tests
Daniel D. Daugherty
dcubed at openjdk.org
Thu Sep 14 18:10:41 UTC 2023
On Thu, 14 Sep 2023 05:44:51 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Similar to [JDK-8315437](https://bugs.openjdk.org/browse/JDK-8315437), current vmTestbase/nsk/monitoring/stress/lowmem tests contains 36 tests, each running exclusively. This drags the tier4 test times up. There seem to be no reason to run these tests exclusively, though: they complete in reasonable time, are moderately-threaded, and consume the usual amount of memory.
>>
>> We should consider enabling parallelism for them and get improved test performance. Currently it is blocked by TEST.properties with exclusiveAccess.dirs directives in them.
>>
>> Current run on 18-core machine:
>> 6385.39s user 8568.61s system 1308% cpu 19:02.97 total
>>
>> Fully parallel:
>> 3885.67s user 295.13s system 2772% cpu 2:30.77 total
>>
>> Additional testing:
>> - [x] 100x Linux x86_64 fastdebug, `vmTestbase/nsk/monitoring/stress/lowmem`
>
>> and consume the usual amount of memory.
>
> And how much is that? And at what concurrency level will we not be able to run these tests in parallel without potentially impacting the way they run i.e. running out of memory sooner than expected?
>
> I'm concerned that these set of PRs to remove exclusive testing are going to cause a headache for those of us who have to monitor and triage CI testing. If I see one of these tests fail after this change goes in, there is nothing to give me any hint as to what has changed - no git log for the test file will show me something was modified!
@dholmes-ora - To make the issue more complicated (sorry), the "tier4" that
@shipilev is talking about is not the same as the Mach5 Tier4 that we use in
our Oracle build/test farm.
@lmesnik should be able to shed light on where in Mach5 he has tested these
recent fixes so that the Oracle GKs know where to be vigilent. I suspect we
won't see these changes until Tier[678], but that's just a guess.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15689#issuecomment-1719913938
More information about the serviceability-dev
mailing list