On Wed, Jun 11, 2014 at 1:26 PM, Ian Daniher <[email protected]> wrote:
> Output of "make check" for those of you who are interested. > > failures: > [run-pass] run-pass/intrinsic-alignment.rs > [run-pass] run-pass/rec-align-u64.rs > These are failing because it seems like we just overlooked adding the right cases for non-android arm & mips. I filed a bug here: https://github.com/mozilla/rust/issues/14848 > [run-pass] run-pass/stat.rs > I'm not too sure as to why this one is failing. I'll try and figure it out later. > > test result: FAILED. 1469 passed; 3 failed; 32 ignored; 0 measured > > > > On Wed, Jun 11, 2014 at 12:15 PM, Ian Daniher <[email protected]> > wrote: > >> I have a dual core arm machine with 1GB of RAM keeping up with rust >> master - every 8hrs, it updates git, runs "make install," and 8hrs later I >> have an up-to-date rustc w/ libs. >> >> No swap, no compression kmods, just a build of rustc & libs that passes >> (almost) all tests. >> >> root@debian-0d0dd:/mnt/armscratch/node-v0.10.28# free -h; uname -a; cat >>> /proc/cpuinfo; rustc -v >>> total used free shared buffers cached >>> Mem: 1.0G 982M 24M 0B 155M 750M >>> -/+ buffers/cache: 76M 930M >>> Swap: 0B 0B 0B >>> Linux debian-0d0dd 3.4.79-r0-s20-rm2+ #54 SMP Tue Feb 18 01:09:07 YEKT >>> 2014 armv7l GNU/Linux >>> Processor : ARMv7 Processor rev 4 (v7l) >>> processor : 0 >>> BogoMIPS : 1819.52 >>> processor : 1 >>> BogoMIPS : 1819.52 >>> Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 >>> tls vfpv4 idiva idivt >>> CPU implementer : 0x41 >>> CPU architecture: 7 >>> CPU variant : 0x0 >>> CPU part : 0xc07 >>> CPU revision : 4 >>> Hardware : sun7i >>> Revision : 0000 >>> Serial : 0000000000000000 >>> rustc 0.11.0-pre (f92a8fa 2014-06-10 18:07:07 -0700) >>> host: arm-unknown-linux-gnueabihf >> >> >> >> >> On Tue, Jun 10, 2014 at 5:19 PM, Igor Bukanov <[email protected]> wrote: >> >>> I tried building rust in a VM with 1GB of memory and it seems only >>> zswap works. With zram-only solution without any real swap I was not >>> able to compile rust at all. The compiler generated out-of-memory >>> exception with zram configured to take 30-70% of memory. With zswap >>> enabled, zswap.max_pool_percent=70 and the real swap of 2.5 GB the >>> compilation time for the latest tip was about 2 hours. This is on Mac >>> Air and Linux inside VirtualBox. >>> >>> On 5 June 2014 20:46, Ian Daniher <[email protected]> wrote: >>> > zram is a great suggestion, thanks! I'll give it a shot. >>> > — >>> > From My Tiny Glowing Screen >>> > >>> > >>> > On Thu, Jun 5, 2014 at 2:25 PM, Igor Bukanov <[email protected]> wrote: >>> >> >>> >> Have you considered to use zram? Typically the compression for >>> >> compiler memory is over a factor of 3 so that can be an option as the >>> >> performance degradation under swapping could be tolerable. A similar >>> >> option is to enable zswap, but as the max compression with it is >>> >> effectively limited by factor of 2, it may not be enough to avoid >>> >> swapping. >>> >> >>> >> On 5 June 2014 20:13, Ian Daniher <[email protected]> wrote: >>> >> > 1GB is close-ish to the 1.4GB last reported (over a month ago!) by >>> >> > http://huonw.github.io/isrustfastyet/mem/. >>> >> > >>> >> > Are there any workarounds to push the compilation memory down? I'm >>> also >>> >> > exploring distcc, but IRFY has a bit of semantic ambiguity as to >>> whether >>> >> > or >>> >> > not it's 1.4GB simultaneous or net total. >>> >> > >>> >> > Thanks! >>> >> > -- >>> >> > Ian >>> >> > >>> >> > _______________________________________________ >>> >> > Rust-dev mailing list >>> >> > [email protected] >>> >> > https://mail.mozilla.org/listinfo/rust-dev >>> >> > >>> > >>> > >>> >> >> > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
