On Sun, Dec 04, 2016 at 05:25:49AM +0100, Guillem Jover wrote:
> Hi!
>
> On Fri, 2016-12-02 at 10:31:58 +0100, Guillem Jover wrote:
> > Right, this was reported the other day on IRC by Mattia Rizzolo. The
> > combination of -Sextreme -z9 and parallel xz makes this use more than
> > the available address space. I'll change the code to limit based on
> > memory available. Although as was mentioned on a thread on d-d, those
> > settings are pretty unfriendly IMO, even more for memory constrained
> > arches, but oh well. dpkg should never fail to operate on those
> > conditions.
>
> I've got the attached patch now, but I've been unable to test that
> specific incarnation as I don't have 32-bit machine with many cores.
> And neither are the i386 nor armhf porter boxes. I've just verified
> that it does what it is intended by hardcoding the number of threads
> to 32 and setting the physical memory limit to 2 GiB. And it reduced
> the threads down to 12 when building one of those font packages.
>...
Your patch won't solve it - the problem is not physical memory.
The problem is that on 32 bit you cannot use more than 2-3 GB
(depending on the architecture) in one process.
#845757 was on a mipsel buildd with 4 cores [1] and 8 GB RAM.
I don't know how much RAM the amd64/i386 buildds have,
but I'd guess more than 4 GB...
A hard upper limit somewhere around 1.5 GB on all 32 bit architectures
(or on all architectures, if that's easier to implement) is required.
(I'd also suggest a MBF for all the packages that mess with the
compressor for no good reason - just like the ones using bzip2
this only causes troubles.)
> Thanks,
> Guillem
cu
Adrian
[1] 4x 674 MiB with -9 > 2 GB limit on 32bit mips/mipsel
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
