Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
- To: Luke Kenneth Casson Leighton <firstname.lastname@example.org>
- Cc: Ivo De Decker <email@example.com>, debian-mips <firstname.lastname@example.org>, ARM <email@example.com>, firstname.lastname@example.org, email@example.com
- Subject: Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
- From: Aurelien Jarno <firstname.lastname@example.org>
- Date: Wed, 14 Aug 2019 18:12:56 +0200
- Message-id: <[🔎] 20190814161256.GA3912@aurel32.net>
- Mail-followup-to: Luke Kenneth Casson Leighton <email@example.com>, Ivo De Decker <firstname.lastname@example.org>, debian-mips <email@example.com>, ARM <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org
- In-reply-to: <[🔎] CAPweEDxiLg8cum6w0cxSrfSp_AYf1FV1BSRN8bU2N+FtpY_v7w@mail.gmail.com>
- References: <[🔎] 20190808203857.GA4365@aurel32.net> <[🔎] email@example.com> <[🔎] CAPweEDxiLg8cum6w0cxSrfSp_AYf1FV1BSRN8bU2N+FtpY_v7w@mail.gmail.com>
On 2019-08-09 16:26, Luke Kenneth Casson Leighton wrote:
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> On Fri, Aug 9, 2019 at 1:49 PM Ivo De Decker <firstname.lastname@example.org> wrote:
> > Hi Aurelien,
> > On 8/8/19 10:38 PM, Aurelien Jarno wrote:
> > > 32-bit processes are able to address at maximum 4GB of memory (2^32),
> > > and often less (2 or 3GB) due to architectural or kernel limitations.
> > [...]
> > Thanks for bringing this up.
> > > 1) Build a 64-bit compiler targeting the 32-bit corresponding
> > > architecture and install it in the 32-bit chroot with the other
> > > 64-bit dependencies. This is still a kind of cross-compiler, but the
> > > rest of the build is unchanged and the testsuite can be run. I guess
> > > it *might* be something acceptable. release-team, could you please
> > > confirm?
> > As you noted, our current policy doesn't allow that. However, we could
> > certainly consider reevaluating this part of the policy if there is a
> > workable solution.
> it was a long time ago: people who've explained it to me sounded like
> they knew what they were talking about when it comes to insisting that
> builds be native.
> fixing binutils to bring back the linker algorithms that were
> short-sightedly destroyed "because they're so historic and laughably
> archaic why would we ever need them" should be the first and only
> absolute top priority.
> only if that catastrophically fails should other options be considered.
> with the repro ld-torture code-generator that i wrote, and the amount
> of expertise there is within the debian community, it would not
> surprise me at all if binutils-ld could be properly fixed extremely
> a proper fix would also have the advantage of keeping linkers for
> *other* platforms (even 64 bit ones) out of swap-thrashing, saving
> power consumption for build hardware and costing a lot less on SSD and
> HDD regular replacements.
That would only fix ld, which is only a small part of the issue. Do you
also have ideas about how to fix llvm, gcc or rustc which are also
affected by virtual memory exhaustion on 32-bit architectures?
Aurelien Jarno GPG: 4096R/1DDD8C9B