Re: RFC: Changing default ggc-min-expand on mips and mipsel?
Aurelien Jarno <[email protected]>
| Newsgroups | gmane.linux.debian.ports.mips |
|---|---|
| Message-ID | <[email protected]> |
On 2016-10-18 15:04, James Cowgill wrote: > 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. Ok, I'll work on a patch for the debian package then. The next question is which value should we use? 30% like if the machine had no RAM? 20% like used by some packages? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://www.aurel32.net
signature.asc
(application/pgp-signature, 801 B)
-----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYBo4EAAoJELqceAYd3YybsCMP/3//Axc4A/RvG985VPW4v8By QKh/QWVAOzlI8Tm9bmdp3jMILuO50E7u0hPobMB4oQzcJErCDfCPhyhe/60ehjK7 5TB16/SdIZ1xUAwoMA3nlB0psb9YyWxd2wULxqiiZ1Kj6rmg57niJcPmsxQNCuZ1 avyk6fGjHWZuTReZby+bFCkPw2j5OuzvMWojIiNNtgi/1fNDkyD8ZedXW7HV70uu JVeE2idUpMPukIWYXrjTgYHh9Nib/JvRN5SujFBREhXxs5Z7K62d4RISVq1AY3Df bgEnzL02Qr/FUdfhVneoPLFhgemKh7a0PRlus+x5XleQ2grYeev5P0BwDhswVlDc TdLSwHwHzLQ7oFKwxGD27Ob3pif4t+h/UxVMvgVdsYLjJXXuux6HwdmvUIM4y29X EskyI+nDj8pYhYR+RCz1F8o1n8G/N7ZnWhfunBoB6AkszqWgQpJBa8GYO63CUI1c aee6jdINCgELiG++2R00gKjz5rCA3Wz+Qa5IqrY2DTWf6tg+uf4AcxUHRGSpiC52 lQALrCLYXMY+pt8mSAvHHH4tH9mkF8j/qeyCqDPZr9m5LXqq1jdxCTfWffAI6i7Y MITbJ9/bHmqG6jMKmjm7ElIZFlVYh5hQJwkHzh01EURNdf1kOSml8kvxeKnitvjh u16GVX0aVCg8P6T4l/ct =vMD6 -----END PGP SIGNATURE-----