* [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests @ 2024-02-01 19:20 John David Anglin 2024-02-29 23:02 ` Thomas Schwinge 0 siblings, 1 reply; 7+ messages in thread From: John David Anglin @ 2024-02-01 19:20 UTC (permalink / raw) To: GCC Patches [-- Attachment #1: Type: text/plain, Size: 1539 bytes --] Tested on hppa-unknown-linux-gnu. Committed to trunk. Dave --- Set num_threads to 50 on 32-bit hppa in two libgomp loop tests We support a maximum of 50 threads on 32-bit hppa. 2024-02-01 John David Anglin <danglin@gcc.gnu.org> libgomp/ChangeLog: * testsuite/libgomp.c++/loop-3.C: Set num_threads to 50 on 32-bit hppa. * testsuite/libgomp.c/omp-loop03.c: Likewise. diff --git a/libgomp/testsuite/libgomp.c++/loop-3.C b/libgomp/testsuite/libgomp.c++/loop-3.C index fa50f099f3f..3f460f114bf 100644 --- a/libgomp/testsuite/libgomp.c++/loop-3.C +++ b/libgomp/testsuite/libgomp.c++/loop-3.C @@ -1,3 +1,9 @@ +#if defined(__hppa__) && !defined(__LP64__) +#define NUM_THREADS 50 +#else +#define NUM_THREADS 64 +#endif + extern "C" void abort (void); int a; @@ -19,7 +25,7 @@ foo () int main (void) { -#pragma omp parallel num_threads (64) +#pragma omp parallel num_threads (NUM_THREADS) foo (); return 0; diff --git a/libgomp/testsuite/libgomp.c/omp-loop03.c b/libgomp/testsuite/libgomp.c/omp-loop03.c index 7bb9a194331..9879981cf4a 100644 --- a/libgomp/testsuite/libgomp.c/omp-loop03.c +++ b/libgomp/testsuite/libgomp.c/omp-loop03.c @@ -1,3 +1,9 @@ +#if defined(__hppa__) && !defined(__LP64__) +#define NUM_THREADS 50 +#else +#define NUM_THREADS 64 +#endif + extern void abort (void); int a; @@ -19,7 +25,7 @@ foo () int main (void) { -#pragma omp parallel num_threads (64) +#pragma omp parallel num_threads (NUM_THREADS) foo (); return 0; [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests 2024-02-01 19:20 [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests John David Anglin @ 2024-02-29 23:02 ` Thomas Schwinge 2024-02-29 23:17 ` John David Anglin 0 siblings, 1 reply; 7+ messages in thread From: Thomas Schwinge @ 2024-02-29 23:02 UTC (permalink / raw) To: John David Anglin; +Cc: gcc-patches, Tobias Burnus, Jakub Jelinek Hi! On 2024-02-01T19:20:57+0000, John David Anglin <dave@parisc-linux.org> wrote: > Tested on hppa-unknown-linux-gnu. Committed to trunk. > Set num_threads to 50 on 32-bit hppa in two libgomp loop tests > > We support a maximum of 50 threads on 32-bit hppa. What happens if you go higher? Curious, what/why is that architectural limit of 50 threads? 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. Grüße Thomas > --- a/libgomp/testsuite/libgomp.c++/loop-3.C > +++ b/libgomp/testsuite/libgomp.c++/loop-3.C > @@ -1,3 +1,9 @@ > +#if defined(__hppa__) && !defined(__LP64__) > +#define NUM_THREADS 50 > +#else > +#define NUM_THREADS 64 > +#endif > + > extern "C" void abort (void); > int a; > > @@ -19,7 +25,7 @@ foo () > int > main (void) > { > -#pragma omp parallel num_threads (64) > +#pragma omp parallel num_threads (NUM_THREADS) > foo (); > > return 0; > --- a/libgomp/testsuite/libgomp.c/omp-loop03.c > +++ b/libgomp/testsuite/libgomp.c/omp-loop03.c > @@ -1,3 +1,9 @@ > +#if defined(__hppa__) && !defined(__LP64__) > +#define NUM_THREADS 50 > +#else > +#define NUM_THREADS 64 > +#endif > + > extern void abort (void); > int a; > > @@ -19,7 +25,7 @@ foo () > int > main (void) > { > -#pragma omp parallel num_threads (64) > +#pragma omp parallel num_threads (NUM_THREADS) > foo (); > > return 0; ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests 2024-02-29 23:02 ` Thomas Schwinge @ 2024-02-29 23:17 ` John David Anglin 2024-03-01 8:29 ` Tobias Burnus 0 siblings, 1 reply; 7+ messages in thread From: John David Anglin @ 2024-02-29 23:17 UTC (permalink / raw) To: Thomas Schwinge, John David Anglin Cc: gcc-patches, Tobias Burnus, Jakub Jelinek, Helge Deller On 2024-02-29 6:02 p.m., Thomas Schwinge wrote: > Hi! > > On 2024-02-01T19:20:57+0000, John David Anglin <dave@parisc-linux.org> wrote: >> Tested on hppa-unknown-linux-gnu. Committed to trunk. >> Set num_threads to 50 on 32-bit hppa in two libgomp loop tests >> >> We support a maximum of 50 threads on 32-bit hppa. > What happens if you go higher? Curious, what/why is that architectural > limit of 50 threads? One gets an EAGAIN error at 51. I don't know why 50 is the architectural limit on hppa-linux. I had asked Helge previously but didn't get an answer. As far as I can tell, limit isn't set by glibc. It seems 64 is supported on all other targets. > > 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. Dave -- John David Anglin dave.anglin@bell.net ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests 2024-02-29 23:17 ` John David Anglin @ 2024-03-01 8:29 ` Tobias Burnus 2024-03-01 8:44 ` Jakub Jelinek 0 siblings, 1 reply; 7+ messages in thread From: Tobias Burnus @ 2024-03-01 8:29 UTC (permalink / raw) To: John David Anglin, Thomas Schwinge, John David Anglin Cc: gcc-patches, Jakub Jelinek, Helge Deller Hi all, hi John & Thomas 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. However, I guess that the thread limit also affects 'teams' and nested parallelization. And for teams 'num_teams(n)' sets lower = upper value to 'n' — Thus, this enforces this number of teams. (While 'num_teams(m:n)' sets both limits and 'omp_set_num_teams(n)' or OMP_NUM_TEAMS=n only set the upper bound). [As far as I can see, OpenACC always permits an implementation to use fewer gangs/workers/vectors if the hardware doesn't support the requested number.] Tobias ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests 2024-03-01 8:29 ` Tobias Burnus @ 2024-03-01 8:44 ` Jakub Jelinek 2024-03-01 9:01 ` Helge Deller 2024-03-01 22:24 ` John David Anglin 0 siblings, 2 replies; 7+ messages in thread From: Jakub Jelinek @ 2024-03-01 8:44 UTC (permalink / raw) To: Tobias Burnus Cc: John David Anglin, Thomas Schwinge, John David Anglin, gcc-patches, Helge Deller 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests 2024-03-01 8:44 ` Jakub Jelinek @ 2024-03-01 9:01 ` Helge Deller 2024-03-01 22:24 ` John David Anglin 1 sibling, 0 replies; 7+ messages in thread From: Helge Deller @ 2024-03-01 9:01 UTC (permalink / raw) To: Jakub Jelinek, Tobias Burnus Cc: John David Anglin, Thomas Schwinge, John David Anglin, gcc-patches On 3/1/24 09:44, Jakub Jelinek wrote: > 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? On my physical parisc machines I see: root@panama(4GB RAM):~# cat /proc/sys/kernel/threads-max 39696 root@parisc(8GM RAM):~# cat /proc/sys/kernel/threads-max 63861 So, I wonder where the 50 comes from. On parisc stacks grow upwards and the initial maximum stack size is limited, so maybe this influences the 50 ? Helge ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests 2024-03-01 8:44 ` Jakub Jelinek 2024-03-01 9:01 ` Helge Deller @ 2024-03-01 22:24 ` John David Anglin 1 sibling, 0 replies; 7+ messages in thread From: John David Anglin @ 2024-03-01 22:24 UTC (permalink / raw) To: Jakub Jelinek, Tobias Burnus Cc: Thomas Schwinge, John David Anglin, gcc-patches, Helge Deller On 2024-03-01 3:44 a.m., Jakub Jelinek wrote: > Isn't this just that you have 50 in there? No. It's okay. The problem is we run out of memory caused by a "ulimit -s 81920" statement that I had in .bashrc. The test pass with default stack allocation. clone(child_stack=0x3191040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[1108], tls=0x81918c0, child_tidptr=0x8191468) = 1108 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 mmap2(NULL, 83890176, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 ENOMEM (Cannot allocate memory) Will revert change to tests. Dave -- John David Anglin dave.anglin@bell.net ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-03-01 22:24 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-02-01 19:20 [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests John David Anglin 2024-02-29 23:02 ` Thomas Schwinge 2024-02-29 23:17 ` John David Anglin 2024-03-01 8:29 ` Tobias Burnus 2024-03-01 8:44 ` Jakub Jelinek 2024-03-01 9:01 ` Helge Deller 2024-03-01 22:24 ` John David Anglin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).