Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)
On Fri, Jun 29, 2018 at 5:21 PM, Steve McIntyre <steve@einval.com> wrote:
>>2G is also way too little memory these days for a new buildd.
>
> Nod - lots of packages are just too big for that now.
apologies for repeating it again: this is why i'm recommending people
try "-Wl,--no-keep-memory" on the linker phase as if it works as
intended it will almost certainly drastically reduce memory usage to
the point where it will stay, for the majority of packages, well
within the 2GB limit i.e. within resident RAM.
i'm really not sure why the discussions continue not to take this
into account, repeating the status-quo and accepting "packages are too
big" as if there is absolutely no possible way that this problem may
be solved or even attempted to be solved... ever. i am very confused
by this. perhaps it is down to latency in discussions as new people
contribute (but have signficant delay on reading), i don't know.
> Future options
> ==============
>
> I understand DSA's reluctance to continue supporting dev boards as
> build platforms - I've been the one working on some of these machines
> in the machine room at Arm, and it's painful when you can't reliably
> reboot or get onto the console of crashed machines. We've also had a
> spate of disk failures recently which has caused extended downtime.
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".
... oh, i have an idea which people might like to consider trying.
it's to use "-Wl,--no-keep-memory" on the linker phase of 32-bit
builds. did i mention that already? :) it might save some build
hardware from being destroyed if people try using
"-Wl,--no-keep-memory"!
> I'm just in the middle of switching the arm64 machines here to using
> SW RAID to mitigate that in future, and that's just not an option on
> the dev boards. We want to move away from dev boards for these
> reasons, at the very least.
most of them won't have native SATA: very few 32-bit ARM systems do.
GbE is not that common either (so decent-speed network drives are
challenging, as well). so they'll almost certainly be USB-based
(USB-to-SATA, which is known-unreliable), and putting such vast
amounts of drive-hammering through USB-to-SATA due to thrashing isn't
going to help :)
the allwinner A20 and R40 are the two low-cost ARM systems that i'm
aware of that have native SATA.
there is however a new devboard that is reasonably cheap and should
be available really soon: the Rock64Pro (not to be confused with the
Rock64, which does NOT have PCie), from pine64:
https://www.pine64.org/?page_id=61454
it's one of the first *low-cost* ARM dev-boards that i've seen which
has 4GB of RAM and has a 4x PCIe slot. the team have tested it out
with an NVMe SSD and also 4x SATA PCIe cards: they easily managed to
hit 20 Gigabits per second on the NVMe drive (2500 mbytes/sec).
also worth noting, they're working on a 2U rackmount server which
will have i think something insane like 48 Rock64Pro boards in one
full-length case.
the Rock64Pro uses the RK3399 which is a 4-core CortexA53 plus 2-core
CortexA72 for a total 6-core SMP system, all 64-bit.
if anyone would like me to have a word with TL Lim (the CEO of
pine64) i can see if he is willing and able to donate some Rock64Pro
boards to the debian farm, let me know.
l.
Reply to: