1. 06 Nov, 2014 5 commits
    • Wesley Bland's avatar
      Return request from IRECV even if failure · 5b0cfb3b
      Wesley Bland authored
      We will now return a request handle from MPI_IRECV even if there is a
      failure. The reason for this is because the ULFM spec says that even if
      the function returns MPIX_ERR_PROC_FAILED_PENDING, it still should
      provide a valid request that can be completed later.
      This doesn't cause a problem for other situations because the value of
      the request is undefined in that scenario so it's fine for it to be
      Signed-off-by: default avatarHuiwei Lu <huiweilu@mcs.anl.gov>
    • Wesley Bland's avatar
      Check for pending any source ops · c2be640e
      Wesley Bland authored
      Before calling the progress engine, make sure none of the operations
      should return an error for MPIX_ERR_PROC_FAILED_PENDING. They would
      cause the progress engine to hang (potentially) so we can't enter it.
      Instead, mark the appropriate error codes and return immediately.
      Signed-off-by: default avatarHuiwei Lu <huiweilu@mcs.anl.gov>
    • Wesley Bland's avatar
      Check for any source reqs that should be pending · e89e6c66
      Wesley Bland authored
      Anysource requests involving a communicator that isn't collectively
      active should be appended to the posted queue the error class should be
      marked as MPIX_ERR_PROC_FAILED_PENDING. The operation can still be
      completed later.
      Signed-off-by: default avatarHuiwei Lu <huiweilu@mcs.anl.gov>
    • Wesley Bland's avatar
      Add MPID_Request_is_pending_failure · d71154aa
      Wesley Bland authored
      This function will check to see if a request can be completed if it
      involves MPI_ANY_SOURCE. An any source request cannot be completed if
      the communicator is not collectively active.
      Signed-off-by: default avatarHuiwei Lu <huiweilu@mcs.anl.gov>
    • Kenneth Raffenetti's avatar
      portals4: temporarily buf counts in ptl_nm.c · 42ebe240
      Kenneth Raffenetti authored
      There is a complete overhaul of this file on the way, but in the meantime
      we raise these limits to prevent deadlock in MPI_Finalize with process
      count >= 12.
      No reviewer.
  2. 05 Nov, 2014 19 commits
  3. 04 Nov, 2014 9 commits
    • Min Si's avatar
      Add req RMA op tests checking local completion. · db61d8d8
      Min Si authored
      Rput/accumulate + wait guarantees local completion, which means we can
      modify local buffer after wait is finished. These two tests check the local
      completion of Rput and Raccumulate by modifying local buffer after wait
      and then checking remote data. We expect the remote data should be equal
      to the local data before modifying.
      Signed-off-by: default avatarXin Zhao <xinzhao3@illinois.edu>
    • Min Si's avatar
      Bug-fix: trigger OnFinal at end when receiving multiple segments. · ea444c34
      Min Si authored
      There are two request handlers used when receiving data:
      (1) OnDataAvail, which is triggered when data is arrived;
      (2) OnFinal, which is triggered when receiving data is finished;
      In progress engine, only OnDataAvail is triggered when a request is
      completed. The upper ch3 layer should change OnDataAvail to OnFinal when
      the coming receiving data will complete the request.
      However, in the original implementation, when receiving multiple
      segments for a large receive data, the OnDataAvail was reset to 0
      at the last segment hence the final action was lost. This patch fixed
      this bug.
      In RMA target put/acc/gacc packet handlers, OnDataAvail was reset to
      OnFinal function if OnDataAvail is 0 due to this bug. This patch also
      rewrites this part so that packet handlers only sets proper OnFinal
      handler at beginning and let the receiving data function change
      OnDataAvail to OnFinal at the last segment.
      Signed-off-by: default avatarXin Zhao <xinzhao3@illinois.edu>
    • Min Si's avatar
      Implement true request-based RMA operations. · 3e005f03
      Min Si authored
      There are two requests associated with each request-based
      operation: one normal internal request (req) and one newly
      added user request (ureq). We return ureq to user when
      request-based op call returns.
      The ureq is initialized with completion counter (CC) to 1
      and ref count to 2 (one is referenced by CH3 and another
      is referenced by user). If the corresponding op can be
      finished immediately in CH3, the runtime will complete ureq
      in CH3, and let user's MPI_Wait/Test to destroy ureq. If
      corresponding op cannot be finished immediately, we will
      first increment ref count to 3 (because now there are
      three places needed to reference ureq: user, CH3,
      progress engine). Progress engine will complete ureq when
      op is completed, then CH3 will release its reference during
      garbage collection, finally user's MPI_Wait/Test will
      destroy ureq.
      The ureq can be completed in following three ways:
      1. If op is issued and completed immediately in CH3
      (req is NULL), we just complete ureq before free op.
      2. If op is issued but not completed, we remember the ureq
      handler in req and specify OnDataAvail / OnFinal handlers
      in req to a newly added request handler, which will complete
      user reqeust. The handler is triggered at three places:
         2-a. when progress engine completes a put/acc req;
         2-b. when get/getacc handler completes a get/getacc req;
         2-c. when progress engine completes a get/getacc req;
      3. If op is not issued (i.e., wait for lock granted), the 2nd
      way will be eventually performed when such op is issued by
      progress engine.
      Signed-off-by: default avatarXin Zhao <xinzhao3@illinois.edu>
    • Junchao Zhang's avatar
      Uncomment some code in F08 since the cce bug is fixed · 73859c0e
      Junchao Zhang authored
      It was commented out due to a cce/8.3.0 bug. Since the bug is fixed in cce/8.3.2,
      we can safely uncomment the code.
      No reviewer
    • Kenneth Raffenetti's avatar
      portals4: create separate EQ for origin events · 5c1bd3d4
      Kenneth Raffenetti authored
      An EQ for origin events is useful for rate-limiting operations so that
      a process does not locally trigger a flow control event on its portal.
      We will implement the rate-limiting logic in the rportals layer.
      Signed-off-by: default avatarAntonio J. Pena <apenya@mcs.anl.gov>
    • Kenneth Raffenetti's avatar
      portals4: create EQ using limit from NI init · c443c852
      Kenneth Raffenetti authored
      Rather than use an EQ limit that may be lower than the system default,
      just create our EQ using the returned maximum from PtlNIInit.
      Signed-off-by: default avatarAntonio J. Pena <apenya@mcs.anl.gov>
    • Junchao Zhang's avatar
      Rename enum MPICH_WITHIN_MPI to MPICH_IN_INIT · 9ea630d0
      Junchao Zhang authored
      The new enum name is more descriptive to describle an MPIR_MPI_State_t
      that says MPICH is in initialization but not completely finished.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Junchao Zhang's avatar
      Make MPI_Initialized and friends thread-safe · 435ce800
      Junchao Zhang authored
      Implements MPI-Forum ticket 357 (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/357
      The ticket will be included in MPI-3.1, which adds thread-safety to MPI_INITIALIZED,
      In MPICH, we make MPIR_Process.mpich_state atomic. After MPI is fully initialized, i.e.,
      in POST_INIT state, MPI_QUERY_THREAD, MPI_IS_THREAD_MAIN are inherently thread-safe.
      Fixes #2137
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Junchao Zhang's avatar
      Code clean up for enum MPIR_MPI_State_t · dfb872fe
      Junchao Zhang authored
      Also remove numbering for each enum, which is not necessary and is
      hard to maintain.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
  4. 03 Nov, 2014 7 commits
    • Xin Zhao's avatar
      add original RMA PVARs back. · ed20cd37
      Xin Zhao authored
      Add some original RMA PVARs back to the new
      RMA infrastructure, including timing of packet
      handlers, op allocation and setting, window
      creation, etc.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Pavan Balaji's avatar
      Remove namespacing for static functions and types. · b682ec0e
      Pavan Balaji authored
      Names of static functions and types need not to have
      namespacing. Here we remove prefix MPIDI_CH3I_ for
      those functions and types.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Delete no longer needed code. · cc63b367
      Xin Zhao authored
      We made a huge change to RMA infrastructure and
      a lot of old code can be droped, including separate
      handlers for lock-op-unlock, ACCUM_IMMED specific
      code, O(p) data structure code, code of lazy issuing,
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Rewrite code of passive lock control messages. · 0542e304
      Xin Zhao authored
      1. Piggyback LOCK request with first IMMED operation.
      When we see an IMMED operation, we can always piggyback
      LOCK request with that operation to reduce one sync
      message of single LOCK request. When packet header of
      that operation is received on target, we will try to
      acquire the lock and perform that operation. The target
      either piggybacks LOCK_GRANTED message with the response
      packet (if available), or sends a single LOCK_GRANTED
      message back to origin.
      2. Rewrite code of manage lock queue.
      When the lock request cannot be satisfied on target,
      we need to buffer that lock request on target. All we
      need to do is enqueuing the packet header, which contains
      all information we need after lock is granted. When
      the current lock is released, the runtime will goes
      over the lock queue and grant the lock to the next
      available request. After lock is granted, the runtime
      just trigger the packet handler for the second time.
      3. Release lock on target side if piggybacking with UNLOCK.
      If there are active-message operations to be issued,
      we piggyback a UNLOCK flag with the last operation.
      When the target recieves it, it will release the current
      lock and grant the lock to the next process.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Reset the start of the enum to 0. · 7fbe72dd
      Xin Zhao authored
      We must make the initial value of enum to zero because some places
      check number of packet types by checking ending type value.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Rearrange enum of pkt types. · be3e5bdd
      Xin Zhao authored
      Rearrange the ordering of packet types so that all RMA issuing types
      can be placed together. This is convenient when we check if currently
      involved packets are all RMA packets.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Simplify PktHandler_FOP and PktHandler_FOPResp. · a42b916d
      Xin Zhao authored
      For FOP operation, all data can be fit into the packet
      header, so on origin side we do not need to send separate
      data packets, and on target side we do not need request
      handler, only packet handler is needed. Similar with FOP
      response packet, we can receive all data in FOP resp packet
      handler. This patch delete the request handler on target
      side and simplify packet handler on target / origin side.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>