[
https://issues.apache.org/jira/browse/LUCENE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022827#comment-17022827
]
Robert Muir commented on LUCENE-9165:
-------------------------------------
{quote}
don't know if it's worth complicating the script though (those who have such
fancy machines can always override in ~/gradle.properties?).
{quote}
Yes, let users with fancy machines simply do this. Let's not have such
craziness in our build to try to be magical. Look at how complicated it can
get: https://bugs.openjdk.java.net/browse/JDK-6515172
And besides, even if we do it "by the book", we would get it wrong and guess 16
for David's case in LUCENE-9160. Looks/sounds like kvm is not configured
properly and has 16 "vcpu" mapped to only 8 real cores on the host, which we
can't see. So we could have all that complicated logic only to get it wrong
anyway.
It is java's problem to deal with: let's keep it as simple as possible.
> change generate-defaults.gradle not to cap testsJvms at 4
> ---------------------------------------------------------
>
> Key: LUCENE-9165
> URL: https://issues.apache.org/jira/browse/LUCENE-9165
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Robert Muir
> Priority: Major
> Attachments: LUCENE-9165.patch
>
>
> {code}
> def cpus = Runtime.runtime.availableProcessors()
> def testsJvms = (int) Math.max(1d, Math.min(cpus * 0.5d, 4))
> {code}
> Dividing by 2 is still good (hyperthreading is still a thing), but the
> artificial cap of 4 is a bottleneck if the hardware has more available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
