<div dir="ltr">Thanks, Reid and Pavel!<div><br></div><div>On Fri, Nov 27, 2015 at 1:21 PM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think it sounds like something that would be useful in general. I'd<br>
even go a step further and say that we can replace the current flakey<br>
test mechanism with your proposed solution.</blockquote><div><br></div><div>Okay, I like that idea.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If we do that (remove the<br>
current flakey mechanism when this is in place), then I think it would<br>
be super-great as we don't increase the number of moving parts and we<br>
can think of this as just an upgrade of an inferior solution (the<br>
current flakey mechanism has always felt like a hack to me) with a<br>
better one.<br></blockquote><div><br></div><div>Sounds great.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you want to automatically re-run tests, then we can have a mode<br>
that does that, but I'd like to have it off by default. I have several<br>
reasons for this:<br>
- you get to feel bad for having to add flakey decorators, which may<br>
encourage you to fix things<br>
- if you make a change (hopefully only locally :) ) which breaks a lot<br>
of tests, you want this to fail quickly instead of waiting for reruns<br>
- if you make a change that makes things flakey (!), you may not<br>
actually notice it because of the reruns<br>
<br></blockquote><div><br></div><div>I'm fine with that.  The only caveat I see is that it appears we have a largish number of potential-failing tests under high load, so we may end up (at least on OS X) marking quite a few up this way.  But, that's also helpful since it lets us see which of the tests really are failing under load.  So this is all likely for the best, with a small ramp-up time to while we "discover" which tests are hitting this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
cheers,<br>
pl<br></blockquote><div><br></div><div>Thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<br>
<br>
On 27 November 2015 at 18:58, Todd Fiala via lldb-dev<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
> Note this is similar to the flakey test mechanism, with the primary<br>
> difference being that the re-run is done in a minimal CPU load environment<br>
> rather than wherever the failure first occurred.  The existing flakey test<br>
> rerun logic is not helpful for the high-load-induced failures that I'm<br>
> looking to handle.<br>
><br>
> On Fri, Nov 27, 2015 at 10:56 AM, Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> On OS X (and frankly on Linux sometimes as well, but predominently OS X),<br>
>> we have tests that will sometimes fail when under significant load (e.g.<br>
>> running the concurrent test suite, exacerbated if we crank up the number of<br>
>> threads, but bad enough if we run at "number of concurrent workers == number<br>
>> of logical cores").<br>
>><br>
>> I'm planning on adding a serialized, one-worker-only phase to the end of<br>
>> the concurrent test run, where the load is much lighter since only one<br>
>> worker will be processing at that phase.  Then, for tests that fail in the<br>
>> first run, I'd re-run them in the serialized, single worker test run phase.<br>
>> On the OS X side, this would eliminate a significant number of test failures<br>
>> that are both hard to diagnose and hard to justify spending significant<br>
>> amounts of time on in the short run.  (There's a whole other conversation to<br>
>> have about fixing them for real, i.e. working through all the race and/or<br>
>> faulty test logic assumptions that are stressed to the max under heavier<br>
>> load, but practically speaking, there are so many of them that this is going<br>
>> to be impractical to address in the short/mid term.).<br>
>><br>
>> My question to all of you is if we'd want this functionality in top of<br>
>> tree <a href="http://llvm.org" rel="noreferrer" target="_blank">llvm.org</a> lldb.  If not, I'll do it in one of our branches.  If so, we<br>
>> can talk about possibly having a category or some other mechanism if we want<br>
>> to mark those tests that are eligible to be run in the follow-up serialized,<br>
>> low-load pass.  Up front I was just going to allow any test to fall into<br>
>> that bucket.  The one benefit to having it in top of tree <a href="http://llvm.org" rel="noreferrer" target="_blank">llvm.org</a> is that,<br>
>> once I enable test reporting on the green dragon public <a href="http://llvm.org" rel="noreferrer" target="_blank">llvm.org</a> OS X LLDB<br>
>> builder, that builder will be able to take advantage of this, and will most<br>
>> certainly tag fewer changes as breaking a test (in the case where the test<br>
>> is just one of the many that fail under high load).<br>
>><br>
>> Let me know your thoughts either way.<br>
>><br>
>> Thanks!<br>
>> --<br>
>> -Todd<br>
><br>
><br>
><br>
><br>
> --<br>
> -Todd<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div></div>