On Dec 12, 2008, at 11:46 AM, Eugene Loh wrote:
> FWIW, I've run into the need for this a few times due to HPCC tests
> on large (>100 MPI procs) nodes or multicore systems. HPCC (among
> other things) looks at the performance of a single process while all
> other np-1 processes spinwait -- or of a single pingpong pair while
> all other np-2 processes wait. I'm not 100% sure what's going on,
> but I'm guessing that the hard spinning of waiting processes hits
> the memory system or some other resource, degrading the performance
> of working processes. This is on nodes that are not oversubscribed.
I guess I could <waving hands> see how shmem kinds of communication
could lead to this kind of bottleneck, and that increasing core counts
would magnify the effect. It would be good to understand if shmem
activity is the cause of the slowdown to know if this is a good
rationale datapoint for whether we should do blocking progress (or,
more specifically, whether we need to increase the priority of
implementing blocking progress).