<div dir="ltr">Actually, scratch that: <div><br></div><div>The three single-NVIDIA GPU jobs also occupy 1.5 (read: 2) nodes for 5+ minutes, Thus the NVIDIA jobs in _isolation_ limit our total theoretical CI throughput to 5 changes per hour, not counting that they also compete with the AMD OpenCL job for those nodes.</div><div><br></div><div>This is the reason the logs of those jobs sometimes spend the first 15-20 minutes waiting for pods to become available.</div><div><br></div><div>In other words: They have to go ;-)</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 28, 2020 at 5:29 PM Erik Lindahl &lt;<a href="mailto:erik.lindahl@gmail.com">erik.lindahl@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><div><br></div><div>Couldn&#39;t help to continue looking, so one more observation ;-)</div><div><br></div><div>We need to be much more careful about adding jobs requesting GPUs. There are presently three different jobs requesting a single NVIDIA device, and two different jobs requesting two NVIDIA devices, and each of them need ~5 minutes just for the tests.</div><div><br></div><div>We only have two nodes with 2 devices each (both AMD and NVIDIA). If each of these two nodes have a job running requesting a single GPU, no 2-GPU jobs can run. Similarly, the two dual-NVIDIA-GPU jobs blocks the entire available CI infrastructure for 5+ minutes for every single change (meaning our throughput is limited to  ~10 changes per hour).</div><div><br></div><div>It&#39;s definitely convenient to be able to run CI tests on two devices, but that&#39;s the type of job that should finish in less than 30 seconds ;-)</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 28, 2020 at 5:15 PM Paul Bauer &lt;<a href="mailto:paul.bauer.q@gmail.com" target="_blank">paul.bauer.q@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto">Hello,<div dir="auto"><br></div><div dir="auto">I started to set up tests that can run as jobs after a commit is merged, and we should just see that we get this code in to reduce the stress on the hardware. All the slow jobs can then be moved there.</div><div dir="auto"><br></div><div dir="auto">/Paul</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 28 Sep 2020, 17:00 Erik Lindahl, &lt;<a href="mailto:erik.lindahl@gmail.com" target="_blank">erik.lindahl@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Good point, but it also shows we have some homework to do. Our new CI infrastructure was quite expanded (~80 high end cores, 2GB/core, all SSD disks) - but this only seems to have led all of us to happily add tests that took more time.<br>
<br>
Looking just briefly at the pipelines, it seems the testing phase is our main culprit. While it is of course nice to have per-change tests, I don&#39;t think it&#39;s sustainable that we need 10+ CPU hours of testing for every typo fix.<br>
<br>
In particular these tests need attention:<br>
<br>
- gmx-api. They both take 12-15 minutes on two cores, and there are four of them. <br>
<br>
- TSAN &amp; ASAN. I don&#39;t think we can justify using 8 cores for 15-20 min for each of them.<br>
<br>
- OpenCL, likely related to slow kernel compiles, which gets even worse when the AMD GPUs become a bottleneck.<br>
<br>
<br>
I also suspect that quite a few tests asking for lots of cores and memory don&#39;t really use all of it (at least not efficiently), but as a result other CI jobs will have to wait.<br>
<br>
There&#39;s also a huge difference in performance between proper unit tests called on code level vs. the ones that issue commands or even run simulations.<br>
<br>
This week is not the one to change things, but IMHO we need to get back to the original model of the CI tests for every change executing FAST. Any test job that doesn&#39;t complete in less than ~3 min on a single core does not belong among the ones that are run for every change.<br>
<br>
Cheers,<br>
<br>
Erik<br>
<br>
<br>
<br>
<br>
Erik Lindahl &lt;<a href="mailto:erik.lindahl@scilifelab.se" rel="noreferrer" target="_blank">erik.lindahl@scilifelab.se</a>&gt;<br>
Professor of Biophysics<br>
Science for Life Laboratory<br>
Stockholm University &amp; KTH<br>
Office (SciLifeLab): +46 8 524 81567<br>
Cell (Sweden): +46 73 4618050<br>
Cell (US): +1 (650) 924 7674 <br>
<br>
<br>
<br>
&gt; On 28 Sep 2020, at 16:23, Eric Irrgang &lt;<a href="mailto:ericirrgang@gmail.com" rel="noreferrer" target="_blank">ericirrgang@gmail.com</a>&gt; wrote:<br>
&gt; <br>
&gt; Hi Devs,<br>
&gt; <br>
&gt; If you push a new commit to a GitLab branch before the pipelines are finished running for the previous commit, please consider canceling one or the other sets of pipelines.<br>
&gt; <br>
&gt; You can look at the Pipelines tab of the merge request page (or just go to <a href="https://gitlab.com/gromacs/gromacs/-/pipelines" rel="noreferrer noreferrer" target="_blank">https://gitlab.com/gromacs/gromacs/-/pipelines</a>). If you have pushed a new commit, you are presumably only interested in one (of the sets of) pipelines. Just click the red X to cancel the pipelines you don&#39;t need.<br>
&gt; <br>
&gt; If you are pushing to a branch that doesn&#39;t have an MR yet, you are still generating one pipeline for every push, so please use the web interface to cancel the pipelines that aren&#39;t useful to you.<br>
&gt; <br>
&gt; It will really help all of us to get our CI pipelines to run sooner.<br>
&gt; <br>
&gt; Thanks!<br>
&gt; M. Eric Irrgang<br>
&gt; -- <br>
&gt; Gromacs Developers mailing list<br>
&gt; <br>
&gt; * Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
&gt; <br>
&gt; * Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
&gt; <br>
&gt; * For (un)subscribe requests visit<br>
&gt; <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" rel="noreferrer" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
-- <br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" rel="noreferrer" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div>
-- <br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl &lt;<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>&gt;</div><div>Professor of Biophysics, Dept. Biochemistry &amp; Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div></div></div></div></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl &lt;<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>&gt;</div><div>Professor of Biophysics, Dept. Biochemistry &amp; Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div></div></div></div></div></div></div></div></div>