On Fri, Jun 29, 2018 at 5:21 PM, Steve McIntyre <st...@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.
