On Tue, Oct 30, 2012 at 5:56 PM, Sander Pronk <span dir="ltr"><<a href="mailto:pronk@kth.se" target="_blank">pronk@kth.se</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Oct 30, 2012, at 14:28 , Szilárd Páll <<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>> wrote:</div><br><blockquote type="cite">
On Tue, Oct 30, 2012 at 8:49 AM, Sander Pronk <span dir="ltr"><<a href="mailto:pronk@kth.se" target="_blank">pronk@kth.se</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
What's the practical difference between the two cases? In both cases, the thread is allowed to run on all CPUs in the system, right?<br></blockquote><div><br></div><div>The practical difference is that if we run on an 8-core CPU:</div>
<div>mdrun -ntmpi 1 -ntomp 4</div><div>we lock the threads to the first four cores, but if we run</div><div>taskset 0xFF mdrun -ntmpi 1 -ntomp 4</div><div>without distinguishing between the two cases I've just mentioned, we would override the affinity set by taskset. Of course, the above does not make much sense, but I would rather not have mdrun exhibit ambiguous behavior.</div>
</div></blockquote><div><br></div><div><br></div></div><div>In that case we can could go for a rule that says that we'll only *refine* a user-set affinity (use fewer CPUs for a given thread than actually requested), never *expand* it (use CPUs we were told not to run on). </div>
</div></div></blockquote><div><br></div><div>Sounds good.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>
BTW in my experience, hwloc-ps doesn't always give consistent results (especially with icc).</div></div></div></blockquote><div><br></div><div>I have never seen inconsistencies, but have not checked very much either. What kind of inconsistencies did you notice?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="h5"><div><br></div><br><blockquote type="cite"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
On Oct 30, 2012, at 00:32 , Szilárd Páll <<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> In order to be nice and not have mdrun override externally set CPU affinities I want to check whether the affinity is default or it has been changed (by taskset, OpenMP library, etc.). Initially I want to implement this for GNU platforms with sched.h.<br>
><br>
> While I initially though if no affinity is set the cpu set should be empty, in fact it in this case CPU_ISSET will give the same result as if all CPUs were in the set -- which actually makes sense. However, this left me quite clueless about how to distinguish between the case when all CPUs are present in the cpu set and when e.g. all CPU are set by taskset, e.g.<br>
> $ taskset 0xF mdrun # quite useless on a quad-core machine<br>
><br>
> Does anybody have an idea how to distinguish these two cases. It would be possible, because e.g. hwloc-ps can do it (but they do it based on their own mask-representation which makes is a bit hard to figure out what I need from their code).<br>
><br>
> Thanks,<br>
> --<br>
> Szilárd<br>
><br>
</div></div><span><font color="#888888">> --<br>
> gmx-developers mailing list<br>
> <a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
> <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
> Please don't post (un)subscribe requests to the list. Use the<br>
> www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
<br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</font></span></blockquote></div><br>
-- <br>gmx-developers mailing list<br><a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br><a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the <br>www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div>
</div></div><br></div><br>--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br>