Yes, I missed that point before - too early in the morning :-/ As I said in my last note, it would be nice to either have a flag indicating we are bound, or see all the cpu info so we can compute that we are bound. Either way, we still need to have a complete picture of all I/O devices so you can compute the distance.
On Feb 9, 2012, at 6:01 AM, nadia.der...@bull.net wrote: > > > devel-boun...@open-mpi.org wrote on 02/09/2012 01:32:31 PM: > > > De : Ralph Castain <r...@open-mpi.org> > > A : Open MPI Developers <de...@open-mpi.org> > > Date : 02/09/2012 01:32 PM > > Objet : Re: [OMPI devel] btl/openib: get_ib_dev_distance doesn't see > > processes as bound if the job has been launched by srun > > Envoyé par : devel-boun...@open-mpi.org > > > > Hi Nadia > > > > I'm wondering what value there is in showing the full topology, or > > using it in any of our components, if the process is restricted to a > > specific set of cpus? Does it really help to know that there are > > other cpus out there that are unreachable? > > Ralph, > > The intention here is not to show cpus that are unreachable, but to fix an > issue we have at least in get_ib_dev_distance() in the openib btl. > > The problem is that if a process is restricted to a single CPU, the algorithm > used in get_ib_dev_distance doesn't work at all: > I have 2 ib interfaces on my victim (say mlx4_0 and mlx4_1), and I want the > openib btl to select the one that is the closest to my rank. > > As I said in my first e-mail, here is what is done today: > . opal_paffinity_base_get_processor_info() is called to get the number of > logical processors (we get 1 due to the singleton cpuset) > . we loop over that # of processors to check whether our process is bound > to one of them. In our case the loop will be executed only once and we will > never get the correct binding information. > . if the process is bound actually get the distance to the device. > in our case, the distance won't be computed and mlx4_0 will be seen as > "equivalent" to mlx4_1 in terms of distances. This is what I definitely want > to avoid. > > Regards, > Nadia > > > > > On Feb 9, 2012, at 5:15 AM, nadia.der...@bull.net wrote: > > > > > > > > devel-boun...@open-mpi.org wrote on 02/09/2012 12:20:41 PM: > > > > > De : Brice Goglin <brice.gog...@inria.fr> > > > A : Open MPI Developers <de...@open-mpi.org> > > > Date : 02/09/2012 12:20 PM > > > Objet : Re: [OMPI devel] btl/openib: get_ib_dev_distance doesn't see > > > processes as bound if the job has been launched by srun > > > Envoyé par : devel-boun...@open-mpi.org > > > > > > By default, hwloc only shows what's inside the current cpuset. There's > > > an option to show everything instead (topology flag). > > > > So may be using that flag inside > > opal_paffinity_base_get_processor_info() would be a better fix than > > the one I'm proposing in my patch. > > > > I found a bunch of other places where things are managed as in > > get_ib_dev_distance(). > > > > Just doing a grep in the sources, I could find: > > . init_maffinity() in btl/sm/btl_sm.c > > . vader_init_maffinity() in btl/vader/btl_vader.c > > . get_ib_dev_distance() in btl/wv/btl_wv_component.c > > > > So I think the flag Brice is talking about should definitely be the fix. > > > > Regards, > > Nadia > > > > > > > > Brice > > > > > > > > > > > > Le 09/02/2012 12:18, Jeff Squyres a écrit : > > > > Just so that I understand this better -- if a process is bound in > > > a cpuset, will tools like hwloc's lstopo only show the Linux > > > processors *in that cpuset*? I.e., does it not have any visibility > > > of the processors outside of its cpuset? > > > > > > > > > > > > On Jan 27, 2012, at 11:38 AM, nadia.derbey wrote: > > > > > > > >> Hi, > > > >> > > > >> If a job is launched using "srun --resv-ports --cpu_bind:..." and slurm > > > >> is configured with: > > > >> TaskPlugin=task/affinity > > > >> TaskPluginParam=Cpusets > > > >> > > > >> each rank of that job is in a cpuset that contains a single CPU. > > > >> > > > >> Now, if we use carto on top of this, the following happens in > > > >> get_ib_dev_distance() (in btl/openib/btl_openib_component.c): > > > >> . opal_paffinity_base_get_processor_info() is called to get the > > > >> number of logical processors (we get 1 due to the singleton cpuset) > > > >> . we loop over that # of processors to check whether our process is > > > >> bound to one of them. In our case the loop will be executed only > > > >> once and we will never get the correct binding information. > > > >> . if the process is bound actually get the distance to the device. > > > >> in our case we won't execute that part of the code. > > > >> > > > >> The attached patch is a proposal to fix the issue. > > > >> > > > >> Regards, > > > >> Nadia > > > >> > > <get_ib_dev_distance.patch>_______________________________________________ > > > >> devel mailing list > > > >> de...@open-mpi.org > > > >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > > > > > > > _______________________________________________ > > > devel mailing list > > > de...@open-mpi.org > > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel_______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel