On Fri, Mar 01, 2024 at 09:29:01AM +0100, Tobias Burnus wrote:
> John David Anglin wrote:
> > On 2024-02-29 6:02 p.m., Thomas Schwinge wrote:
> > > I wonder: shouldn't that cap at 50 threads happen inside libgomp,
> > > generally, instead of per test case and user code (!)?
>
> > > Per my
> > > understanding, OpenMP 'num_threads' specifies a *desired* number of
> > > threads; the implementation may limit that value.
> > Sounds like a good suggestion.
>
> I concur – if the hardware/OS doesn't support more.
>
> * * *
>
> However – for completeness and to correct a statement: While num_threads
> specifies the desired number of threads, 'strict' will turn this into error
> termination if the implementation cannot fulfilled the request.
>
> Namely, "if prescriptiveness is specified as 'strict' and Algorithm 11.1
> would result in a number of threads other than the value of the first item
> of the _nthreads_ list then runtime error termination is performed."
>
> Note that 'strict' for num_threads is new in/since the OpenMP 6.0 draft
> (TR11, I think) and not yet implemented in GCC.
Also note that if hppa-linux really has such low thread limits, we can't
simply try to add some hack in gomp_resolve_num_threads where it would lower
the result if larger than 50, because if the limit is max 50 threads per
process, just doing nested parallelism and asking for 25 threads in the
outer and 4 in the inner in each will run over that limit, or teams 4
with max 25 threads in parallel inside of it, or user can use pthread_create
in the process as well, etc.
So, if at all possible, the best thing would be to change kernel so that
the number of threads is limited just by available memory for stacks and
user tweakable limit.
E.g. on my ws I have
cat /proc/sys/kernel/threads-max
253865
Isn't this just that you have 50 in there?
Jakub
