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

Reply via email to