RE: RFC: Changing default ggc-min-expand on mips and mipsel?
Hi, It seems that we have usually used 20% or less, but I am not sure if this is minimal requested value for all of them. May we could try to rebuild a few packages and see how it behaves if we increase it to 30% (or 20)? Regards, Dejan From: Aurelien Jarno [aurel...@aurel32.net] Sent: Tuesday, October 18, 2016 11:03 PM To: James Cowgill Cc: debian-mips@lists.debian.org Subject: Re: RFC: Changing default ggc-min-expand on mips and mipsel? 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 aurel...@aurel32.net http://www.aurel32.net
Re: RFC: Changing default ggc-min-expand on mips and mipsel?
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 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: RFC: Changing default ggc-min-expand on mips and mipsel?
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 Description: OpenPGP digital signature
RFC: Changing default ggc-min-expand on mips and mipsel?
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 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
