https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96844
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
Last reconfirmed| |2023-01-16
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=44833
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
I got an internal Arm report about the same behaviour. Like you say, they
don't see the problem with LLVM's and Intel's libraries.
https://github.com/xianyi/OpenBLAS/pull/3546#issuecomment-1153914479 is a
discussion about the same problem in an OpenBLAS context.
Some other places where the question has come up:
- https://stackoverflow.com/a/52821175
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71781
I suppose the question is what to do instead. As
[https://github.com/xianyi/OpenBLAS/pull/3546#issuecomment-1154817082]
says, past behaviour isn't necessarily an indication of future behaviour, so a
simple counter- or time-based reaping heuristic is likely to create unexpected
cliff-edges.
>From my reading of the LLVM libomp sources, it looks like it doesn't reap
threads until:
- library shutdown
- omp_pause_resource(omp_pause_hard, ...) or
omp_pause_resource_all(omp_pause_hard) is called
(__kmp_allocate_team also reaps teams that are too small for the request, but
the comments indicate that that's temporary.)
I could well be wrong: there could well be other situations in which LLVM reaps
threads too.
Still, would it be OK/useful to have an environment variable that selects the
same behaviour in libgomp?
