Re: RFC: Changing default ggc-min-expand on mips and mipsel?
James Cowgill <[email protected]>
| Newsgroups | gmane.linux.debian.ports.mips |
|---|---|
| Message-ID | <[email protected]> |
Hi, On 18/10/16 13:49, Aurelien Jarno wrote: > 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? I think this is a good idea since it is almost "free" and we don't have to change lots of packages. I also think changing it on other 32-bit arches is a good idea, although they're not as affected as much since that have an extra 1GB of virtual memory. James
signature.asc
(application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJYBivzAAoJEMfxZ23qLQHv9fQQAILghQVCRAdvICBb4EA4AS4R 86D1Qx6EgefdI0bsnyeAGURtUfMROW8au4xEwjR1oR9gMYGFhW80CS/YpNPR/Y5k sLgOZ0bJQVWDQTED8rB+lMzfK9YGXCm8YgVsjd3nUhBq/o9iC1aaSTuIsgpmtNhr gvYzYLOu/HjgL3sAj2N0Jx6tE/uYIuUloHX3UUlLdiv4JNlbdrTU//lHWZ6ZCmmw oJwxR2gxZuPzkP1wOtQPlUCAqaP1tyrnwnyFf6m5bP2ClW4KekoSvkpmXjlXlBv1 OO1wuxYmNiaswvblY9KACcGVtFP8SaH9tTpdBj7wXJ8hcVIxER3jVX7T7R/AU362 S+ZkYlFgLnwp7i3fiM/RBswlqtlecjzh/ryyzpFK8nqNk0HUEwSvwjPnCO18ohWM 1DnWA+U3KZ5cXOusIAc9gWfPJSp636DHMoDoMgrjcTjAyvq7SPftO7JKSXrcEf30 htbrbwToCraqKaOIYDSrlPIDwDMbmh/QUo3SoF3Mh0a679J3ydhqaBGbrppqtmu2 rsO90yB8AD9oVwyyer41t046Uey6sMqRe7sHBFM9tK3vUlPY7p4OKK7buvXGRelY ky83y1NIYRnJlkvLRo232FA679q8VY2p4ftcZgSmjznn4RtFbyvkkVXzCQds4X1y 8Ph0o7BV8nsK0jaR1KHs =4Ydw -----END PGP SIGNATURE-----