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

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

> 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*.


Reply to: