<div dir="ltr">Hi,<br><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 25, 2016 at 10:08 PM Szilárd Páll &lt;<a href="mailto:pall.szilard@gmail.com">pall.szilard@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div>On Mon, Apr 25, 2016 at 9:22 PM, Mark Abraham <span dir="ltr">&lt;<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>&gt;</span> wrote:<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 class="gmail_quote"><span><div dir="ltr">On Mon, Apr 25, 2016 at 8:56 PM Szilárd Páll &lt;<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@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"><div class="gmail_extra"><div><div>On Mon, Apr 25, 2016 at 8:46 PM, Mark Abraham <span dir="ltr">&lt;<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>&gt;</span> wrote:<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 class="gmail_quote"><span><div dir="ltr">On Mon, Apr 25, 2016 at 7:19 PM Szilárd Páll &lt;<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@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">Confirmed, we&#39;ve ran into it last Friday and 5820 seemed to fix the issue, but as the author of the change noted, it&#39;s is unclear what the source of the crash is.<div><br></div><div>BTW: we need to add a &quot;-pin on&quot; test to the verification matrix  to make sure the thread pinning code gets tested. It can be post-submit too, but we have none of those on the horizon so better add an otpion to the current ones IMO.</div></div></blockquote><div><br></div></span><div>Yes and no. Doing it that way<br>* doesn&#39;t test the code any more than that it doesn&#39;t crash,<br></div>* creates another degree of freedom of coverage for a matrix to manage, and<br><div>* creates a situation where Jenkins could thrash if enough threads get pinned to a common core<br><br></div><div>Much better is a unit test </div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>I partially agree, a unit test would be suitable to verify the functionality of the pinning code in isolation from the &quot;outer world&quot;. However, it will not be able to control external conditions (e.g. affinity set outside mdrun) - which I was going to mention bu it slipped my mind.<br></div></div></div></div></div></blockquote><div><br></div></span><div>I&#39;m not sure what case you&#39;re referring to. I don&#39;t think we can reasonably test that some external method has set affinity and that it doesnt work, in a way that a user or developer could act upon. We only have to test that when the user asks for pinning that it will work.<br></div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I am referring to the case where mdrun either backs off or overrides affinities. We expect -pin on to work regardless of the original content of the mask, right?</div><div><br></div><div>Lots of ways to influence affinity:</div><div>taskset 0x1 gmx mdrun ...</div><div>hwloc-bind core:0-3 gmx mdrun ...</div><div>GOMP_CPU_AFFINITY=0-4 gmx mdrun<br></div></div></div></div></blockquote><div><br></div><div>Sure, but what behaviour is there for us to test? We can test that if we detect external affinity setting that we do nothing unless -pin on, but that&#39;s just trivial logic. I think we have no need to try to set the external condition and observe that the API permits us to detect the conditions that were set up for the test binary. (Though that could change if there was evidence that stuff didn&#39;t work - I&#39;m just aware of none.)<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"><div><div class="gmail_quote"><div>That -pin auto and -pin on have different behaviours under different combinations of inputs is its own standalone unit test that requires no external dependency - our job in such a unit test is to test that our logic does what we expect. It&#39;s a separate test that given the output of such logic that we can implement internal pinning - observing success there needs hardware capable of implementing pinning (or not).<br></div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Sure, I agree. That however won&#39;t test whether these give different results:</div><div><br></div><div>GOMP_CPU_AFFINITY=0-1 gmx mdrun -ntmpi 1 -ntomp 3 -pin on<br></div><div>GOMP_CPU_AFFINITY=0-1 gmx mdrun -ntmpi 1 -ntomp 3 -pin auto</div></div></div></div></blockquote><div><br></div><div>The essential difference there is that if external affinity is set, we should respond differently considering the setting of -pin. IIRC the implementation difference there is that we honor the user&#39;s strange request with -pin auto, but perhaps over-ride it with something better when -pin on. But it&#39;s enough to test our logic if we provide synthetic results from querying the OpenMP and/or hardware APIs - and we can get much better coverage of our code paths more easily if we do it that way.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"><div><div class="gmail_quote"><div></div><span><div><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"><div class="gmail_extra"><div class="gmail_quote"><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"><div><div class="gmail_quote"><div>that puts a bunch of unpinned threads doing some simple computation and observes the expected behaviour of similar pinned threads.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Why is doing computation relevant to testing stuff? Pinned or not, threads will execute code correctly.</div></div></div></div></blockquote><div><br></div></span><div>The relevant behaviour is that they don&#39;t migrate in practice. One can&#39;t test for that unless the conditions are such that the kernel might try to migrate them, because there&#39;s plenty of activity and lots of threads. Of course, on PowerPC that aspect of the test will automatically pass.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Well, if the OS reports that threads each have a distinct bit set in their affinity mask, can&#39;t we consider that that a promise that migration won&#39;t happen?</div></div></div></div></blockquote><div><br></div><div>Such a test is merely that if someone has arranged to call the API function, that some visible setting results. We could just as easily call the query function after the set function and give an error if they don&#39;t match. Basically, finding out that running either<br><br></div><div>hwloc -something ./affinity-test<br><br></div><div>or that our own API call to set affinities leads to no bit being set isn&#39;t an observation we can do anything about, except report a bug upstream. I think we should be worrying about getting our own unit tests in place, before considering testing infrastructure common to lots of projects. :-)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> I&#39;m not deeply familiar with different aspects of affinity and whether certain Linux settings may lead to silently ignored affinity masks. Anyone else who knows, please pitch in!</div><div><br></div><div>Otherwise, if we want to get fancy about verifying that pinning works as expected, there should certainly be ways to assess whether migration happens in practice; for instance, could start two groups of threads, one pinned one not (perhaps even under oversubscription) execute CPUID on the pinned threads periodically and see if the core they reside on changes. Can&#39;t provide a proof, but it should be decent evidence I think.<br></div></div></div></div></blockquote><div><br></div><div>Sure. That was my original suggestion. The most important behaviour that we can test is that ostensibly pinned threads do not observe different CPUID values in practice in a realistic scenario. There might even already be code somewhere else that we can re-use.<br><br></div><div>I think the added value of such end-to-end tests (relative to their test-harness complexity) that<br></div><div><br></div><div>gmx mdrun -pin on<br></div><div><br></div><div>actually leads to internally pinned threads, and that<br><br>gmx mdrun -pin auto<br><br>may or may not lead to internally pinned threads, is too low to be worth it, if we have in place unit tests that show<br></div><div>* the command-line option parsing works (done AFAIK),<br></div><div>* that given various synthetic detection results that our combined logic works as we expect, and<br></div><div>* that given a decision to implement internal pinning, that it will work.<br><br></div><div>Mark<br></div><div><br></div><div>Mark<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>--</div><div>Szilárd<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </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"><div><div class="gmail_quote"><div><span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>Mark<br> <br></div></font></span><div><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"><div class="gmail_extra"><div class="gmail_quote"><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"><div><div class="gmail_quote"><div> That can run on every configuration because it can be a unit test that runs in milliseconds. Of course, we wrote this test before we changed the old working code, right?</div></div></div></div></blockquote><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"><div><div class="gmail_quote"><div><span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>Mark<br></div></font></span><div><div><div><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 class="gmail_extra"><br clear="all"><div><div>--<br>Szilárd</div></div></div><div class="gmail_extra">
<br><div class="gmail_quote">On Mon, Apr 25, 2016 at 7:07 PM, Vedran Miletić <span dir="ltr">&lt;<a href="mailto:rivanvx@gmail.com" target="_blank">rivanvx@gmail.com</a>&gt;</span> wrote:<br><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"><div>Gladly. This one? <a href="https://gerrit.gromacs.org/#/c/5820/" target="_blank">https://gerrit.gromacs.org/#/c/5820/</a><span><font color="#888888"><br><br></font></span></div><span><font color="#888888">V.<br></font></span></div><div><div><br><div class="gmail_quote"><div dir="ltr">pon, 25. tra 2016. u 19:06 Mark Abraham &lt;<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>&gt; napisao je:<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"><p dir="ltr">Hi,</p>
<p dir="ltr">Unsure offhand, but there&#39;s a fix in gerrit in this area if you want to try that?</p>
<p dir="ltr">Mark</p>
<br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr">On Mon, 25 Apr 2016 19:05 Vedran Miletić &lt;<a href="mailto:rivanvx@gmail.com" target="_blank">rivanvx@gmail.com</a>&gt; wrote:<br></div></div><div class="gmail_quote"><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>since fa1360610d6fcf7eb263ce1181d9954074fd5151 &quot;Make thread affinity failures always end up in log&quot;, I get crashes in mdrun when using tMPI on any simulation I tried (does not affect OpenMPI). I am seeing this on two machines using Fedora 23 and 24, GCC 5.3 and 6, respectively.<br><br>Backtrace is <br><br>#0  0x00007ffff78c966f in tMPI_Thread_getspecific (key=...) at /home/miletivn/workspace/gromacs/src/external/thread_mpi/src/pthreads.c:571<br>#1  0x00007ffff78cff34 in tMPI_Reduce (sendbuf=0x7fffffffa4dc, recvbuf=0x7fffffffa4d8, count=1, datatype=0x7ffff7dd6660 &lt;tmpi_int&gt;, op=TMPI_LAND, root=0, comm=0x0) at /home/miletivn/workspace/gromacs/src/external/thread_mpi/src/reduce.c:247<br>#2  0x00007ffff63038a5 in invalidWithinSimulation (cr=0x681bd0, invalidLocally=false) at /home/miletivn/workspace/gromacs/src/gromacs/mdrunutility/threadaffinity.cpp:73<br>#3  0x00007ffff6303c0b in get_thread_affinity_layout (fplog=0x689410, cr=0x681bd0, hwinfo=0x680230, threads=8, pin_offset=0, pin_stride=0x7fffffffc634, localityOrder=0x7fffffffc638) at /home/miletivn/workspace/gromacs/src/gromacs/mdrunutility/threadaffinity.cpp:142<br>...<br><br></div><div>Variable key looks like<br><br>$1 = {initialized = {value = 0, padding = &#39;\000&#39; &lt;repeats 59 times&gt;}, key = 0x0}<br><br></div><div>So key is uninitialized. Any idea why?<br></div><div><br></div><div>Regards,<br></div><div>Vedran<br></div></div></blockquote></div><div class="gmail_quote"><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">
--<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>
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>
</div></div><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" 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>.<br></blockquote></div><br></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></div></div></div></div>
<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" 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>.<br></blockquote></div></div></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></div></div></div></div>
<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" 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>.<br></blockquote></div></div></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></div></div>