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

Dejan Latinovic <[email protected]>
Newsgroups gmane.linux.debian.ports.mips
Message-ID <[email protected]>

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 [[email protected]]
Sent: Tuesday, October 18, 2016 11:03 PM
To: James Cowgill
Cc: [email protected]
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
[email protected]                 http://www.aurel32.net
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.