Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Jun 29, 2018 at 8:31 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Luke Kenneth Casson Leighton:
>
>> that is not a surprise to hear: the massive thrashing caused by the
>> linker phase not being possible to be RAM-resident will be absolutely
>> hammering the drives beyond reasonable wear-and-tear limits. which is
>> why i'm recommending people try "-Wl,--no-keep-memory".
>
> Note that ld will sometimes stuff everything into a single RWX segment
> as a result, which is not desirable.
florian, thank you for responding: i've put a copy of the insights
that you give into the bugreport at
https://sourceware.org/bugzilla/show_bug.cgi?id=22831#c16
> Unfortunately, without significant investment into historic linker
> technologies (with external sorting and that kind of stuff),
yes, ah ha! funnily enough the algorithm that i was asked to create
back in 1988 was an external matrix-multiply, i take it you are
talking about the same thing, where linking is done using explicit
load-process-save cycles rather than relying on swap.
> I don't
> think it is viable to build 32-bit software natively in the near
> future.
i noted an alternative strategy in the bugreport: if binutils *at
the very least* were to look at the available resident RAM and only
malloc'd and used up to that amount, and kept only a few (or even just
one) object file in memory at a time and did all the linking for that,
it would be infinitely better than the current situation which is
*only going to get worse*.
> Maybe next year only a few packages will need exceptions, but
> the number will grow with each month.
well... that ignores the fact that at some point in the next few
years there will be a package that needs 16 GB of resident RAM to
link. and a few years after that it will be 32 GB. and that's on
64-bit systems. the package's name will probably be "firefox", given
the current growth rate.
does debian *really* want to have to upgrade all 64-bit systems in
the build farm first to 16 GB RAM and then to 32 GB and then to 64
GB?? can the powerpc64 systems and all other 64-bit architectures
even *be* upgraded to 16 GB then 32 GB then 64 GB of RAM??
basically the problems faced by 32-bit systems are a warning shot
across the bows about ld not really being kept up-to-date with the
increases in software complexity that's being thrown at it. it's
*NOT* just about 32-bit.
this problem can basically be faced REactively... or it can be faced
PROactively: the historic linker strategies that you mention are i
feel going to be needed in some years' time *even for 64-bit*.
l.
Reply to:
- References:
- Arch qualification for buster: call for DSA, Security, toolchain concerns
- From: Niels Thykier <niels@thykier.net>
- Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj
- From: Uwe Kleine-König <uwe@kleine-koenig.org>
- Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj
- From: Julien Cristau <jcristau@debian.org>
- Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)
- From: Steve McIntyre <steve@einval.com>
- Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)
- From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
- Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)
- From: Florian Weimer <fw@deneb.enyo.de>