Re: [OMPI devel] Rankfile related problems
On Mon, Mar 1, 2010 at 9:15 PM, Ralph Castain wrote: > Tracking this down has reminded me of all the reasons why I despise the > rankfile mapper... :-/ Thanks for all your efforts ! I'm using the rankfile mapper as this is the documented (in the FAQ) affinity-related one at least for the stable series. If there's a better way which I've missed, I'd be eager to learn... > I have created a fix for this mess and will submit it for inclusion in 1.4. I've applied to a 1.4.1 tree the patches from tickets #2318 and #2321 and I can confirm that both problems reported earlier are fixed. > Thanks - not your fault, so pardon the comments. Just had my fill of this > particular code since the creators of it no longer support it. No offense taken :-) I appreciate your efforts and I understand your frustration about unmaintaned code. Thanks again ! Cheers, Bogdan
Re: [OMPI devel] Rankfile related problems
On Tue, Mar 2, 2010 at 4:47 AM, Bogdan Costescu wrote: > On Mon, Mar 1, 2010 at 9:15 PM, Ralph Castain wrote: > > Tracking this down has reminded me of all the reasons why I despise the > rankfile mapper... :-/ > > Thanks for all your efforts ! I'm using the rankfile mapper as this is > the documented (in the FAQ) affinity-related one at least for the > stable series. If there's a better way which I've missed, I'd be eager > to learn... > It depends on what you are trying to do. Rankfile is really only useful if you need to specify rank-by-rank precise bindings. Otherwise, you can specify bind-to-core or bind-to-socket to get a more general automatic binding pattern. You can also specify cores-per-task and get each process bound to the specified number of cores. So there are a lot of options, including rankfile. Unfortunately, I see that these options are not documented on the FAQ or the wiki. :-/ Take a look at "man mpirun" and you'll see more info about all this in the part on process binding options. > > I have created a fix for this mess and will submit it for inclusion in > 1.4. > > I've applied to a 1.4.1 tree the patches from tickets #2318 and #2321 > and I can confirm that both problems reported earlier are fixed. > Thanks - appreciate the confirmation! > > > Thanks - not your fault, so pardon the comments. Just had my fill of this > particular code since the creators of it no longer support it. > > No offense taken :-) I appreciate your efforts and I understand your > frustration about unmaintaned code. Thanks again ! > > Cheers, > Bogdan > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
Re: [OMPI devel] Openmpi with slurm : salloc -c
I'm checking with slurm the exact "task_per_node" and "cpus_per_task" behavior, for present and future Slurm version. Ralph Castain a écrit : We've gone around on this one a few times too. We finally settled on the current formula and confirmed it did what the slurm folks expected, so I'm somewhat loath to change it given that situation. I suggest you take it up with the slurm folks to find out what behavior is expected when tasks_per_node and cpus_per_task are set. How many application processes are expected to be run on the node? Part of the problem (as I recall) was that the meaning of tasks_per_node changed across a slurm release. At one time, it actually meant "cpus_per_node", and so you had to do the division to get the ppn correct. I'm not sure what it means today, but since Livermore writes slurm and the folks there seem to be happy with the way this behaves... Let me know what you find out. On Feb 26, 2010, at 9:45 AM, Damien Guinier wrote: Hi Ralph, I find a minor bug on the MCA composent: ras slurm. This one have an incorrect comportement with the "X number of processors per task" feature. On the file orte/mca/ras/slurm/ras_slurm_module.c, line 356: - The node slot number is divide with "cpus_per_task" information, but "cpus_per_task" information is already include by the line 285. My proposition is to not divide the node slot number the seconde time. My patch is : diff -r ef9d639ab011 -r 8f62269014c2 orte/mca/ras/slurm/ras_slurm_module.c --- a/orte/mca/ras/slurm/ras_slurm_module.c Wed Jan 20 18:29:12 2010 +0100 +++ b/orte/mca/ras/slurm/ras_slurm_module.c Thu Feb 25 15:59:41 2010 +0100 @@ -353,7 +353,8 @@ node->state = ORTE_NODE_STATE_UP; node->slots_inuse = 0; node->slots_max = 0; -node->slots = slots[i] / cpus_per_task; +node->slots = slots[i]; opal_list_append(nodelist, &node->super); } free(slots); Tanks Damien
