[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 [aurelien@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
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: