Re: [OMPI devel] ORTE registry patch

[Ralph H Castain]

Thanks - I'll take a look at this (and the prior ones!) in the next couple
of weeks when time permits and get back to you.

Ralph


On 5/23/07 1:11 PM, "George Bosilca"  wrote:

> Attached is another patch to the ORTE layer, more specifically the
> replica. The idea is to decrease the number of strcmp by using a
> small hash function before doing the strcmp. The hask key for each
> registry entry is computed when it is added to the registry. When
> we're doing a query, instead of comparing the 2 strings we first
> check if the hash key match, and if they do match then we compare the
> 2 strings in order to make sure we eliminate collisions from our
> answers.
> 
> There is some benefit in terms of performance. It's hardly visible
> for few processes, but it start showing up when the number of
> processes increase. In fact the number of strcmp in the trace file
> drastically decrease. The main reason it works well, is because most
> of the keys start with basically the same chars (such as orte-
> blahblah) which transform the strcmp on a loop over few chars.
> 
> Ralph, please consider it for inclusion on the ORTE layer.
> 
>Thanks,
>  george.
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] jnysal-openib-wireup branch

[Jeff Squyres]

Nysal --

I was poking through /tmp/jnysal-openib-wireup branch this morning  
(because I suddenly have a need for btl_openib_if_include and  
btl_openib_if_exclude) and found two minor problems:


1. The logic for if_exclude was not correct.  I committed a fix for  
it.  https://svn.open-mpi.org/trac/ompi/changeset/14748


2. I'm a bit confused on a) how the new MCA params mca_num_hcas and  
map_num_procs_per_hca are supposed to be used and b) what their  
default values should be.


2a. I don't quite understand the logic of is_hca_allowed(); I could  
not get it to work properly.  Specifically, I have 2 machines each  
with 2 HCAs (mthca0 has 1 port, mthca1 has 2 ports).  If I ran 2  
procs (regardless of byslot or bynode), is_hca_allowed() would always  
return false for the 2nd proc.  So I put a temporary override in  
is_hca_allowed() to simply always return true.  Can you explain how  
the logic is supposed to work in that function?


2b. The default values of max_num_hcas and map_num_procs_per_hca are  
both 1.  Based on my (potentially flawed) understanding of how these  
MCA params are meant to be used, this is different than the current  
default behavior.  The current default is that all procs use all  
ACTIVE ports on all HCAs.  I *think* your new default param values  
will set each proc to use the ACTIVE ports on exactly one HCA,  
regardless how many there are in the host.  Did you mean to do that?   
Also: both values must currently be >=1; should we allow -1 for both  
of these values, meaning that they can be "infinite" (i.e., based on  
the number of HCAs in the host)?


--
Jeff Squyres
Cisco Systems

Re: [OMPI devel] [OMPI svn] svn:open-mpi r14768

[George Bosilca]

I see the problem this patch try to solve, but I fail to correctly  
understand the implementation. The patch affect all PML and BTL in  
the code base by adding one more argument to some of the most often  
called functions. And there is only one BTL (openib) who seems to use  
it while all others completely ignore it. Moreover, there seems to be  
already a very similar mechanism based on the  
MCA_BTL_DES_FLAGS_PRIORITY flag, which can be set by the PML level  
into the btl_descriptor.


So what's the difference between the additional argument and a  
correct usage of the MCA_BTL_DES_FLAGS_PRIORITY flag ?


  george.

On May 24, 2007, at 3:51 PM, gship...@osl.iu.edu wrote:


Author: gshipman
Date: 2007-05-24 15:51:26 EDT (Thu, 24 May 2007)
New Revision: 14768
URL: https://svn.open-mpi.org/trac/ompi/changeset/14768

Log:
Add optional ordering to the BTL interface.
This is required to tighten up the BTL semantics. Ordering is not  
guaranteed,

but, if the BTL returns a order tag in a descriptor (other than
MCA_BTL_NO_ORDER) then we may request another descriptor that will  
obey

ordering w.r.t. to the other descriptor.


This will allow sane behavior for RDMA networks, where local  
completion of an
RDMA operation on the active side does not imply remote completion  
on the
passive side. If we send a FIN message after local completion and  
the FIN is
not ordered w.r.t. the RDMA operation then badness may occur as the  
passive
side may now try to deregister the memory and the RDMA operation  
may still be

pending on the passive side.

Note that this has no impact on networks that don't suffer from this
limitation as the ORDER tag can simply always be specified as
MCA_BTL_NO_ORDER.





Text files modified:
   trunk/ompi/mca/bml/bml.h |29  
+++
   trunk/ompi/mca/btl/btl.h |10  


   trunk/ompi/mca/btl/gm/btl_gm.c   | 8 ++
   trunk/ompi/mca/btl/gm/btl_gm.h   | 3 ++
   trunk/ompi/mca/btl/mx/btl_mx.c   | 8 ++
   trunk/ompi/mca/btl/mx/btl_mx.h   | 3 ++
   trunk/ompi/mca/btl/openib/btl_openib.c   |49  
++-

   trunk/ompi/mca/btl/openib/btl_openib.h   | 3 ++
   trunk/ompi/mca/btl/openib/btl_openib_endpoint.c  | 7 +++--
   trunk/ompi/mca/btl/openib/btl_openib_frag.c  | 7 +
   trunk/ompi/mca/btl/portals/btl_portals.c | 8 -
   trunk/ompi/mca/btl/portals/btl_portals.h | 3 ++
   trunk/ompi/mca/btl/self/btl_self.c   | 3 ++
   trunk/ompi/mca/btl/self/btl_self.h   | 3 ++
   trunk/ompi/mca/btl/sm/btl_sm.c   | 2 +
   trunk/ompi/mca/btl/sm/btl_sm.h   | 2 +
   trunk/ompi/mca/btl/tcp/btl_tcp.c | 6 
   trunk/ompi/mca/btl/tcp/btl_tcp.h | 3 ++
   trunk/ompi/mca/btl/template/btl_template.c   | 8 -
   trunk/ompi/mca/btl/template/btl_template.h   | 3 ++
   trunk/ompi/mca/btl/template/btl_template_component.c |10 +++ 
+---
   trunk/ompi/mca/btl/udapl/btl_udapl.c |11  
++--

   trunk/ompi/mca/btl/udapl/btl_udapl.h | 3 ++
   trunk/ompi/mca/btl/udapl/btl_udapl_component.c   |17  


   trunk/ompi/mca/osc/rdma/osc_rdma_data_move.c | 3 ++
   trunk/ompi/mca/pml/dr/pml_dr.h   | 6 ++--
   trunk/ompi/mca/pml/dr/pml_dr_sendreq.c   |12  
-

   trunk/ompi/mca/pml/dr/pml_dr_sendreq.h   | 3 +
   trunk/ompi/mca/pml/ob1/pml_ob1.c |17  
-
   trunk/ompi/mca/pml/ob1/pml_ob1.h |44  
+--
   trunk/ompi/mca/pml/ob1/pml_ob1_recvreq.c |14  
+++
   trunk/ompi/mca/pml/ob1/pml_ob1_sendreq.c |28  
--

   32 files changed, 241 insertions(+), 95 deletions(-)


Diff not shown due to size (53504 bytes).
To see the diff, run the following command:

svn diff -r 14767:14768 --no-diff-deleted

___
svn mailing list
s...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/svn




smime.p7s
Description: S/MIME cryptographic signature