API to control whether a PE helps other threads that generate CkLoop/OpenMP/ParallelFor work
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.
#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.