Project

General

Profile

Feature #1480

API to control whether a PE helps other threads that generate CkLoop/OpenMP/ParallelFor work

Added by Phil Miller over 2 years ago. Updated over 1 year ago.

Status:
Merged
Priority:
Normal
Category:
SMP
Target version:
Start date:
01/09/2018
Due date:
% Done:

100%


Description

Jim brought up an issue that he doesn't want the PEs tasked with highly-critical PME work to participate in helping other PEs with work they've shared via node-level parallelism mechanisms, because it may add latency to the PME process. His initial suggestion was extending the various node-level APIs to let the work-generating threads specify which other threads are eligible to help. I suggested an alternative of an API for any PE to call to enable or disable its participation in those constructs to benefit other PEs, and he agreed that would solve his problem easily.

Please add a function along the lines of void CkSetPeHelpsOtherThreads(bool) to control this.

Beware that setting this to false doesn't mean that PE shouldn't work on tasks it generates through the various sharing constructs.

For the sake of getting this into the release and supporting application needs, please take care of this ahead of ongoing development to extend the coverage of the shared-memory APIs.


Subtasks

Documentation #1771: Update on documentation of Loop-level parallelismMergedSeonmyeong Bak

History

#1 Updated by Phil Miller about 2 years ago

  • Target version changed from 6.8.0 to 6.9.0

#2 Updated by Sam White over 1 year ago

This should be near the top of priorities for the Intra-node group for 6.9.0

#3 Updated by Seonmyeong Bak over 1 year ago

  • Status changed from New to In Progress

#4 Updated by Seonmyeong Bak over 1 year ago

Synchronization of the beginning of CkLoop and an event turning on/off the PE Helper bit is an issue for this.

Maybe, considering the PE Helper bits before the beginning of each node-level parallelization is enough to prevent the PEs turning off the bit from being involved in the node-level work.
OpenMP is simple because it uses work-stealing so a PE setting the bit to false can be excluded from helpers by itself after the bit is set false.
CkLoop is kind of tricky because a master PE for each CkLoop work should check whether each target PE's bit before it pushes messages to each PE.
For CkLoop, PE turning off the bit may participate in a CkLoop work.

#5 Updated by Seonmyeong Bak over 1 year ago

  • Status changed from In Progress to Implemented

#7 Updated by Sam White over 1 year ago

  • Status changed from Implemented to Merged

Also available in: Atom PDF