[gmx-developers] checking CPU set

[Sander Pronk]

On Oct 30, 2012, at 14:28 , Szilárd Páll <szilard.pall at cbr.su.se> wrote:

> On Tue, Oct 30, 2012 at 8:49 AM, Sander Pronk <pronk at kth.se> wrote:
> 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?
> 
> The practical difference is that if we run on an 8-core CPU:
> mdrun -ntmpi 1 -ntomp 4
> we lock the threads to the first four cores, but if we run
> taskset 0xFF mdrun -ntmpi 1 -ntomp 4
> 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.


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). 

BTW in my experience, hwloc-ps doesn't always give consistent results (especially with icc).


>  
> 
> On Oct 30, 2012, at 00:32 , Szilárd Páll <szilard.pall at cbr.su.se> wrote:
> 
> > Hi,
> >
> > 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.
> >
> > 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.
> > $ taskset 0xF mdrun # quite useless on a quad-core machine
> >
> > 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).
> >
> > Thanks,
> > --
> > Szilárd
> >
> > --
> > gmx-developers mailing list
> > gmx-developers at gromacs.org
> > http://lists.gromacs.org/mailman/listinfo/gmx-developers
> > Please don't post (un)subscribe requests to the list. Use the
> > www interface or send it to gmx-developers-request at gromacs.org.
> 
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
> 
> -- 
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the 
> www interface or send it to gmx-developers-request at gromacs.org.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20121030/5012d2d6/attachment.html>