RFC: Changing default ggc-min-expand on mips and mipsel?

Aurelien Jarno <[email protected]>
Newsgroups gmane.linux.debian.ports.mips
Message-ID <[email protected]>
Hi all,

On mips and mipsel, we have more and more packages failing to build from
source with a "virtual memory exhausted" error in GCC, due to the 2GB
address space limit. It seems the occurrence is even higher since the
switch to GCC 6. The usual answer has been to play with the
ggc-min-expand GCC parameter, and many packages do that already [1].

The ggc-min expand parameter defaults to "30% + 70% * (RAM/1GB) with an
upper bound of 100% when RAM >= 1GB". In practice all of our build
daemons, but also most of the development machines (including the CI20
board) are bound to 100%. I therefore wonder if we should change the
default at least for mips and mipsel in Debian, and maybe even upstream
for 32-bit architectures.

Any opinion or comment about that?

Thanks,
Aurelien


[1] https://codesearch.debian.net/search?q=ggc-min-expand

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[email protected]                 http://www.aurel32.net
signature.asc (application/pgp-signature, 801 B)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYBhpJAAoJELqceAYd3Yybz7EP/AvhgiaQEIGaqSdwaTIPQYcV
7zpX7/ES/lDM+ASGUK3Rr3fdBfkn/3MTpZkdKekfb/aF7vKTuMwG/UQ78fe7m0y/
DQlasrxpuLVVCvR0a1an5KZvwL97Dukx3DPMyOPpvO01/febaeoLmYi5z7/oqwLB
AUsA/SbxUVF1LVainpiP88GU89d7wMUFeFBQze/49bkoLCcyB/KFkNeEqNwdXNCC
fAOMx5bcBY40d/IUW8Oa3i9xOvpsguFXG7MtfWLtKlUwtP0czY36M3LJ68Eqqk2x
0e25aL2nMrFnPqRK7XkrJl2iRBq1sUm886C3Q+mJmGnfVYNs/J7y9ZdA+4BLNe8w
Bg+zZL4wKZESRApWtca5QZX5a8u3kHOSc8QNsGel1Q0LmPnxeVzVCM41bkWfG5CO
tjo64ISUL8GPHin/mc4oROve0plGdRHLznGXRgDGy8WJg4vn9lWlfIO0BDuGBjZM
9uCGzITc+17f2RYsrm4iMDnHXpISdibpOhRiBxprlks6/bYAmHx/xQZfgVimIMFz
+baF/hfqBNVPPlTZvvB3/oHK9ga//DFoXCfVlY/VUyto3xxNr4jRAAhoYsBLLvV/
FtEja/czSsr6RqaDS0pz2KRddXe1hIFT0SgRJBt5ZCZNun2oNIncIMAGBlVwfLqA
3+8p0ZwP/BQVrUUjwM1u
=I7ry
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.