[zorg] r174421 - Adding cortex-a15 experimental buildbot

[David Blaikie]

On Wed, Feb 6, 2013 at 8:00 AM, David Tweed <david.tweed at arm.com> wrote:
> On 5 February 2013 22:51, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>
>> It might be easier to change to ninja than use ccache.
>
> It would be best is to use both :)
>
>
>
>> Yes, I only said that because David Tweed reported some random crashes on
>> Panda boards when using CCache, so I'm not too keen on leaving it by default
>> on buildbots.
>
>
>
> Hi. I'm a little bit confused: ccache helps in the case that you insist on
> doing a "make clean" before doing a rebuild (because a significant number of
> the files haven't actually changed but you've blown away the .o files) while
> ninja (AIUI) does dependency tracking in the non "make clean" case.
> Personally I think that deliberately not doing a make clean is safe enough
> to be worth trying on a buildbot, particularly if it's the only one of its
> kind. Looking at the output from the a15 buildbot it looks like you are
> choosing to do a "make clean".

Agreed - I've been doing this (though it required an extra step beyond
just avoiding "make clean" - I also had to add in steps to not run
"configure" if it had already been run (by checking for the presence
of the Makefile) - this assumes the make build will automatically
rerun configure if necessary (though I've seen it /not/ do this on at
least one occasion - so it's not perfect)) already on the GDB 7.5
tester to reduce cycle time.

>
>
>
> FWIW, it wasn't quite crashes that I saw using ccache on pandaboards but
> complete lockups of the board. I don't recall seeing anything that looked
> like corruption or a crash (though I often didn't look at results that hard
> so might possibly have missed occasions.) The tentative hypothesis was that
> doing a normal compile the I/O demand is limited by the rate at which the
> CPU can do an actual compile (which effectively slows things down), while
> when using ccache you can get occasions when the I/O demand is limited by
> the rate at which the CPU can hash files (which is quite fast even on mobile
> CPUs) and this higher I/O rate was causing something to lock up on the
> board. But that was just a hypothesis.
>
>
>
> Cheers,
>
> Dave
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>