https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125584
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #8 from Andre Vehreschild <vehre at gcc dot gnu.org> --- > The idea of not changing the memory size for testing was to test what a user > would run. So to say, the test was very successful, because it showed that the > choosen default is to larger for some systems. The current default may be reasonable for regular users running a single program using caf_shmem on their own system. As soon as you're running in a shared environment (e.g. on a multiuser system or in a testsuite run with many tests running in parallel), this is no longer acceptable. > Therefore let's collect opinions on how to resolve this: Should the testsuite > be modified and use a smaller segment size on non-lazy backing memory > allocating OSes? Or should this just be documented and be configured > individually by the runner of the test, i.e. not in the suite, but by a > environment variable on the system the tests run on? Any more thoughts? The testsuite needs to have safe defaults: simply using defaults that a *known* to cause resource exhaustion in some envionments and expecting affected users to search for a workaround and apply them on their own won't do. Imagine a bunch of libgomp tests that uses the default of using <nproc> threads: you'd quickly become very famous (and very much shot down) for such a test. libgomp/testsuite/Makefile.am is extra careful to avoid such a scenario, limiting OMP_NUM_THREADS to 8. The caf tests need to do the same.
