llvm dev - Jul 2020 - MLIR Buildbot configuration

Hi,


I broke the MLIR build yesterday and the two Flang bots told me about it 
pretty much right away. Yay!
That is how I always thought the setup should work (modulo that we all 
try not to break builds).
Today I got emails from an MLIR bot and I was a bit confused. I looked 
at the configuration of the two
MLIR bots and it seems they test commits one by one, with the backlog 
that you would expect.
I was wondering if my observation is correct and if this is the desired 
behavior?
I don't necessarily think such a setup is bad but both MLIR bots run it 
this way, which might catch
more problems but with a longer delay, unsure if it is worth it.


I figured I bring this up but I'm fine when people don't see the need
for change (or more bots).


~ Johannes

Indeed there is quite a backlog here right now:
http://lab.llvm.org:8011/builders/mlir-windows and here
http://lab.llvm.org:8011/builders/mlir-nvidia
I agree that 17 hours of latency is likely too high to justify the
non-batching.

Note that the bots are doing `ninja` first followed by `ninja check-mlir`:
they likely build much more than they need: the build could be faster by
avoiding the first step.

-- 
Mehdi



On Fri, Jul 31, 2020 at 9:05 AM Johannes Doerfert <
johannesdoerfert at gmail.com> wrote:
> Hi,
>
>
> I broke the MLIR build yesterday and the two Flang bots told me about it
> pretty much right away. Yay!
> That is how I always thought the setup should work (modulo that we all
> try not to break builds).
> Today I got emails from an MLIR bot and I was a bit confused. I looked
> at the configuration of the two
> MLIR bots and it seems they test commits one by one, with the backlog
> that you would expect.
> I was wondering if my observation is correct and if this is the desired
> behavior?
> I don't necessarily think such a setup is bad but both MLIR bots run it
> this way, which might catch
> more problems but with a longer delay, unsure if it is worth it.
>
>
> I figured I bring this up but I'm fine when people don't see the
need
> for change (or more bots).
>
>
> ~ Johannes
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200731/01bf6aaa/attachment-0001.html>

+1 for batching.  In practice it's probably more important that things get
run for every MLIR checkin, and not necessarily for every LLVM checkin.

Steve


On Fri, Jul 31, 2020 at 9:26 AM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Indeed there is quite a backlog here right now:
> http://lab.llvm.org:8011/builders/mlir-windows and here
> http://lab.llvm.org:8011/builders/mlir-nvidia
> I agree that 17 hours of latency is likely too high to justify the
> non-batching.
>
> Note that the bots are doing `ninja` first followed by `ninja check-mlir`:
> they likely build much more than they need: the build could be faster by
> avoiding the first step.
>
> --
> Mehdi
>
>
>
> On Fri, Jul 31, 2020 at 9:05 AM Johannes Doerfert <
> johannesdoerfert at gmail.com> wrote:
>
>> Hi,
>>
>>
>> I broke the MLIR build yesterday and the two Flang bots told me about
it
>> pretty much right away. Yay!
>> That is how I always thought the setup should work (modulo that we all
>> try not to break builds).
>> Today I got emails from an MLIR bot and I was a bit confused. I looked
>> at the configuration of the two
>> MLIR bots and it seems they test commits one by one, with the backlog
>> that you would expect.
>> I was wondering if my observation is correct and if this is the desired
>> behavior?
>> I don't necessarily think such a setup is bad but both MLIR bots
run it
>> this way, which might catch
>> more problems but with a longer delay, unsure if it is worth it.
>>
>>
>> I figured I bring this up but I'm fine when people don't see
the need
>> for change (or more bots).
>>
>>
>> ~ Johannes
>>
>> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200731/17ab6182/attachment.html>