some minor updates

Signed-off-by: Edgar Gabriel <[email protected]>

Author: edgargabriel

docs/tuning-apps/accelerators/initialize.rst

@@ -16,15 +16,15 @@ that is set by Open MPI at launch time and can be retrieved before
 ``MPI_Init``. An example code sample using the HIP programming model
 looks as follows:
 
-.. code-block:: sh
+.. code-block:: c
 
    int num_devices;
    hipGetDeviceCount(&num_devices);
    assert (num_devices > 0);
 
    char* ompi_local_rank = getenv("OMPI_COMM_WORLD_LOCAL_RANK");
    if (nullptr != ompi_local_rank) {
-	hipSetDevice(atoi(ompi_local_rank % num_devices));
+	hipSetDevice(atoi(ompi_local_rank) % num_devices);
    }
 
    MPI_Init (&argc, &argv);

docs/tuning-apps/accelerators/memkind.rst

@@ -1,16 +1,19 @@
 Support for Memory-kind Info Objects
 ====================================
 
-`MPI version 4.1. <https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report.pdf>`_  introduced the notion of memory-kinds, which allow an
+`MPI version 4.1. <https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report.pdf>`_
+introduced the notion of memory allocation kinds, which allow an
 application to specify what memory types it plans to use, and to query
 what memory types are supported by the MPI library in a portable
 manner. In addition, the application can place restrictions on certain
 objects such as creating a separate communicator for using with
 host-memory and a communicator that will be used with device memory
 only. This approach allows the MPI library to perform certain
 optimizations, such as bypassing checking the memory-type of buffer
-pointers. Please refer to the MPI specification as well as the
-`Memory Allocation Kinds Side Document <https://www.mpi-forum.org/docs/sidedocs/mem-alloc10.pdf>`_ for more details and examples.
+pointers. Please refer to the MPI specification as well as the `Memory
+Allocation Kinds Side Document
+<https://www.mpi-forum.org/docs/sidedocs/mem-alloc10.pdf>`_ for more
+details and examples.
 
 Open MPI starting from version 6.0.0 supports the following values for the memory allocation kind Info object:
 
@@ -19,21 +22,22 @@ Open MPI starting from version 6.0.0 supports the following values for the memor
 * cuda:device
 * cuda:host
 * cuda:managed
-* level_zero:host
 * level_zero:device
+* level_zero:host
 * level_zero:shared
 * rocm:device
 * rocm:host
 * rocm:managed
 
-.. note:: Support for accelerator memory-kind info objects will depend
-          on the accelerator support compiled into Open MPI.
+.. note:: Support for accelerator memory allocation kind info objects
+          will depend on the accelerator support compiled into Open
+          MPI.
 
 
 Passing memory-kind info to mpiexec
 ===================================
 
-The following example demonstrates how to pass memory-allocation kind
+The following example demonstrates how to pass memory allocation kind
 information to Open MPI at application launch:
 
 .. code:: sh
@@ -57,3 +61,4 @@ communicator will only be used for ROCm device buffers:
 
   MPI_Comm comm_dup
   MPI_Comm_dup_with_info (MPI_COMM_WORLD, info_assert, &comm_dup);
+  ...

docs/tuning-apps/accelerators/rocm.rst

@@ -51,7 +51,7 @@ Runtime querying of ROCm support in Open MPI
 --------------------------------------------
 
 Querying the availability of ROCm support in Open MPI at runtime is
-possible through the memory-kind info object, see ::ref::`memory-kind`
+possible through the memory allocation kind info object, see ::ref::`memkind`
 page for details.
 
 In addition, starting with Open MPI v5.0.0 :ref:`MPIX_Query_rocm_support(3)
@@ -66,15 +66,15 @@ function, the code needs to include ``mpi-ext.h``. Note that
 /////////////////////////////////////////////////////////////////////////
 
 Running single node jobs with ROCm support
--------------------------------------------------------
+------------------------------------------
 
 The user has multiple options for running an Open MPI job with GPU support
 in a single node scenario:
 
 * the default shared memory component ``btl/sm`` has support for
   accelerators, will use however by default a bounce buffer on the CPU
   for data transfers. Hence, while this works, it will not be able to
-  take advantage of the high-speed GPU-to-GPU InfinityFabric (TM)
+  take advantage of the high-speed GPU-to-GPU InfinityFabric
   interconnect (if available).
 
 * to use the high-speed GPU-to-GPU interconnect within a node, the user has to
@@ -166,7 +166,7 @@ ROCm support in Open MPI with libfabric
 ---------------------------------------
 
 Some network interconnects are supported through the libfabric library.
-Configurating libfabric and Open MPI with ROCm support looks something like:
+Configuring libfabric and Open MPI with ROCm support looks something like:
 
 .. code-block:: sh
 
@@ -191,7 +191,7 @@ There are two mechanism for using libfabric and Open MPI with ROCm support.
 
 * Specifying the ``mtl/ofi`` component is sufficient to take advantage
   of the ROCm support in the libraries. In this case, both intra- and
-  inter-node communication will be performed by the libfabric. In
+  inter-node communication will be performed by the libfabric library. In
   order to ensure that the application will make use of the shared
   memory provider for intra-node communication and the network
   interconnect specific provider for inter-node communication, the
@@ -211,7 +211,8 @@ There are two mechanism for using libfabric and Open MPI with ROCm support.
 
 .. code-block:: sh
 
-   # Force using the ofi mtl component
+   # Use the ofi btl for inter-node and sm btl
+   # for intra-node communication
    mpirun --mca pml ob1 --mca btl ofi,sm,tcp,self   \
           --mca smsc_accelerator_priority 80        \
           -n 64 ./<my_executable>
@@ -227,7 +228,7 @@ The ``coll/accelerator`` component supports collective operations on
 ROCm device buffers for many commonly used collective
 operations. The component works by copying data into a temporary host
 buffer, executing the collective operation on the host buffer, and
-copying the data back to the device buffer at completion. This
+copying the result back to the device buffer at completion. This
 component will lead to adequate performance for short to medium data
 sizes, but performance is often suboptimal especially for large reduction
 operations.