On Thu, 14 Sep 2023 05:44:51 GMT, David Holmes <dhol...@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